Re: Default exception handler
dgront wrote:
quite recently I learned about UncaughtExceptionHandler feature in
JAVA 5. For me this is very appealing, because I have a lot of methods
that throw overall a few types of exceptions. So far I had to copy a
relevant try{} catch{} fragment which is common for most of the cases.
....
> The best what I found is to extend RuntimeException (I handle only
> these by my default handler) and to add an enum field to each
> exception. Then I will be able to dispatch exceptions within a switch
> clause.
>
> Can you find a better idea? Or maybe instanceof is good enough, since
> exceptions appear very rarely.
Eric Sosman wrote:
You may have missed an important point: the default
exception handler is a "last gasp" handler that runs just
before an uncaught exception destroys a thread. When the
DEH's uncaughtException() method returns, the thread is
dead, finis, kaput. The uncaughtException() method is not
a catch block.
Even if it worked as the OP expected, it'd be bad style to put one catch-all
handler at the top of the program. The correct place for exception handling
is at the bottom, at the point of first throw, so that it can be properly
logged.
It's a red flag any time one is switching or if()ing on the type of an
argument; it means one has the wrong algorithm. Things should be able to
handle their own stuff - that is, a routine that receives, say, a SQLException
is the one that "knows" it's dealing with SQL stuff, and can properly handle
the exception. A higher level routine that doesn't "care" about SQL shouldn't
have to break encapsulation to find out that SQL was the problem. That should
have been handled already, and the exception either eaten or turned into one
that makes sense at the higher level.
--
Lew