One thing that came out of Lab 1 is how to handle exceptions. Most of the students seem to have some code like the following:

The question here is why do you want to catch the exception? If reading the file failed, the whole application fails and there's nothing more to do, so it seems rather pointless to catch the exception. In fact, catching the exception may even make debugging more difficult, because it kinds of "hide" the error, particularly when the application is running on CS3 and you cannot see the console output.

Exception is introduced in modern programming languages as an alternative to the error code approach used in languages like C. The good thing about exceptions is that you do not have to handle them. In Java you can catch an exception and do something with it, or you can simply declare it and let somebody else to handle it. For example:

As you can see, the code is easier to read, and is likely to be easier to debug because if there's an exception, the application server will display the stack trace in the browser.

So how do we decide whether to catch an exception? The rule of thumb is that if you can do something with the exception and/or if the application can recover from the exception, then catch it; otherwise just declare it.

For our lab problem it makes more sense to declare the exception, but there's a technical problem: adding IOException changes the signature of init() so it no longer overrides the init() in the super class. To work around this problem we can do something called "re-throw" an exception:

Here we just repackage an IOException into a ServletException and pass it along to whoever wants to handle the exception (and in this case it's the application server).

So the morale of the story is that you don't have to catch every exception, and sometimes not catching an exception may even be the right thing to do.

Adam Berman wrote:

As for myself, the reason I chose to catch the file reading exception rather than let it failover is that eclipse complained that I wasn't catching the exception and refused to compile.

I'm sure there's some setting somewhere that would tell it to ignore that, but I figured it'd be easier just to catch it.

In this case you have to catch the exception because you need to override the super class init(), and this is also the reason why Eclipse's Quick Fix will only show "Surround with try/catch" instead of both "Surround with try/catch" and "Add throws declaration". The point is that even in this case you can still re-throw the exception after catching it.