Day 25

Today I was able to start planning my new Limelight FitNesse program, since there is just no way I can expand the sidebar project. I figure I will have a load of players, one for each widget, but they will all be rather uniquely defined. Since the range of widgets is vast, like from an image to making text bold, I think it will be hard to try and follow one format. I am also going to have to do a series of conversions to interpret the Json object that FitNesse will send me, containing the widgets. At the moment, I am think this will be the chain of conversions: Json-> someList -> a widgetInterpreter -> a widget ordering process -> Players -> props and then onto the scene.

While doing some more refactoring today, I learned a lot about the nature of exceptions. When an exception is thrown, the current process will be stopped (although process might not be the right word) and Java will crawl back up the stack until there is a catch block. From there it will continue on. So in memory, a chunk of space is left open in the stack for this catch block (which I believe comes right after the function parameters), and anything below this block will be removed from the stack. An interesting question would be, if we make a thread, and in this thread we throw an exception with no catch block, where will the exception be caught? Will it rise to the top of the thread and just die? I would like to believe Java has some last resort catch so that this thread will still print the exception, and then maybe die right after that, but I am not sure. Also, if you wish to pass a certain type exception even higher, but you need to catch other exceptions at a lower level, then you can first catch the specific exception, and throw it again, then catch all others.

try{
...
} catch (SocketException se){
throw(se)
}
catch(Exception e)
{...}
this way you can migrate all exceptions to where you want them.

On another note:
Liskov Substitution Principle: Subtypes must be substitutable for their base types.
An example of this from Agile Software Development is: "Presume that we have a function f that takes, as its argument, a pointer or reference to some base class B. Presume also that there is some derivative D of B which, when passed to f in the guise of B, causes f to misbehave. Then D violate the LSP."
We came across an example of this today when trying to create a List from an array. There is a method in the Arrays class called .asList(Array array), which as you might guess, apprears to do what we wished; however, when we then tried to remove an item from the list we just made, we got an error that indicated a remove was not possible. Apparently, and correct me if I am wrong, this asList function returned an object masquerading as a List, while really having the array data structure. This was a violation of the LSP.
Reading further into this, another excellent example would be a Square extending a Rectangle. Given that a square need only have 1 side set, and the rectangle requires 2, it is possible to forsee certain errors and fragilities that might arrise.