Re: Java checked exceptions: how do i solve this?
ennioennioennio@gmail.com wrote:
Suppose that the an implementation of
ChildrenLoadingStrategy.loadChildren() contains SQL code. And
SQLExceptions.
Suppose that the another implementation of
ChildrenLoadingStrategy.loadChildren() contains I/O code. And
IOExceptions.
How do i reflect these exceptions in the Node.getChildren() method?
To answer this question, think about the design of your code:
1. What does an SQLException or IOException mean in your case? Is it:
a. User validation error? (Notifying the GUI and refusing to
continue is the best option here)
b. An expected event? (Rewriting it so it isn't expected is the best
option here)
c. A recoverable error? (Propagating a checked exception is best here).
d. A fatal error? (Dieing and logging the error is best here).
Solution 1: declare a brand new Exception that encanpsulates the inner
ones.
void loadChildren(Node node) throws ChildrenLoadingException {
try {
...
} catch(Exception e) {
throws ChildrenLoadingException(e);
}
}
public List<Node> getChildren() throws ChildrenLoadingException {...}
public List<Node> anyOtherMethodInNodeThatCallsGetChildren() throws
ChildrenLoadingException {...}
Comment: Do you like it? i don't. Somehow it "stinks"
This is the preferred method of recovery, but it generally helps to keep
these propagating errors as close to the point of failure as possible.
Solution 2: declare ANY Exception
void loadChildren(Node node) throws Exception {...}
public List<Node> getChildren() throws Exception {...}
public List<Node> anyOtherMethodInNodeThatCallsGetChildren() throws
Exception {...}
Comment: mmmmm.
Horrible and defeats the purpose of checked exceptions.
Solution 3: say goodbye to checked exceptions
void loadChildren(Node node) {
try {
...
} catch(Exception e) {
throws new RuntimeException(e);
}
}
public List<Node> getChildren() {...}
public List<Node> anyOtherMethodInNodeThatCallsGetChildren() {...}
Comment: Terrific! Or maybe better than solution 2?
Even worse than solution 2, by far the worst of all: by the points at
which you start handling recovery, it can become impossible to handle
developer bugs (which are those that tend to subclass RuntimeException:
ArrayIndexOutOfBoundsException, etc.) from real bugs that need error
handling.
What can you suggest me about solution 1, 2 or 3?
Pick solution 1. Purge solutions 2 and 3 from your mind immediately.
They should not be used in any production code.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth