In an email thread, David Castro brought up the question: When should one use checked exceptions in Java? On that note, check out this paper and then read below. It think the paper is well written and helpful: Exception Handling: Common Problems and Best Practice with Java 1.4
On that note, I don't entirely agree with the article. Let me elaborate.
A checked exception mechanism is a way for the compiler to force the programmer to provide code blocks for any number of named possibilities. Presumably, the compiler needs to enforce this because the programmer is: 1) lazy, 2) forgetful or 3) uninformed. Personally, I've seen all three traits in programmers (including myself), so I think it's a reasonable assumption.
A problem arises when the programmer is none of the three. Take the following example (which I'm stealing from the paper):
DateFormat format = DateFormat.getDateInstance(SHORT);
private final static String DEFAULT_DATE_STRING=”01.01.1900”;
try {
Date defaultDate=format.parse(DEFAULT_DATE_STRING);
} catch( ParseException pexc ) {
// Cannot happen: if it works once, it will always work!
}
As the author of the paper points out, even though the format is initialized by a constant, it might be possible for that exception to be thrown in some unusual circumstances: code maintenance affects the constant or there a configuration issue with localization code. Both of those cases are candidates for what the author says are "untreatable situations", however the author of the DateFormat class decided that because the exception *might* be treatable, the exception should be checked. In this case, the programmer is forced to do something with an exception will almost never happen and if the exception occurs, it should probably should just propagate to the top of the application.
Due to the aforementioned problem, I would revise the rule to state that checked exceptions should be used in the case where the options are always treatable. When is something always treatable? Good question. It seems a bit hard to make that assumption. So I tend to favor unchecked exceptions unless you really have good reason to assume all the exceptional cases should be dealt with.
Now, for a completely different line of reasoning. The guiding idea for checked exceptions is that the compiler should force the programmer to deal with the exception, but if it really makes sense to leave it alone, the programmer can just add a "throws" clause and be done with it. Aside from the annoying implication that you have to modify all the calling functions to have the "throws" clause until you get to the place where you are finally ready to deal with the error, there is still the problem that the exception might have to traverse ground that is not controlled by you. For example, suppose you open a file in response to the user pressing a button. You might get a "FileNotFoundException". Well, here, just try the following code out:
public class EventException {
public static void main ( String [] args ) {
(new JButton()).addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent e) {
throw new FileNotFoundException("Oops");
}
});
}
}
The complier complains that you didn't declare the checked exception, but if you try and declare it then the code won't link because the event handler class that calls the "actionPerformed" method doesn't declare the exception.
So, we are left with a modified version of the ideal: if it makes sense for the programmer to leave the exception alone, the programmer can just define the a "throws" clause unless the programmer doesn't control all the methods up the calling stack. Contrast this with the idea of code reusability where we don't want to have to control the code for everything because we want other people to write code that we can use. Put those together and we have a problem.
Now of course, you can wrap the "FileNotFound" exception up in a so-called "evil" unchecked exception, and that's where we started from in the beginning of this conversation.
In summary, you should use checked exceptions if you can guarantee the programmer can deal with all exceptional conditions in the immediate context and will not have a reason to handle the exception further up the calling stack.
Wow, this post ended up being really long. If you are still reading this email at this point in time you should just give up and admit you are a serious programming geek. ;-)
Posted by enigma at June 13, 2006 12:58 PM