Default exception handler

[dgront]

Dear group,

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.

Now I plan to register a UncaughtExceptionHandler (my applications
runs always in a single thread) and to hide all the common code inside
uncaughtException() inherited from Thread.UncaughtExceptionHandler.

This works perfect, but a new problem appeared:

In typical try{} catch{} block I can handle different types of
exceptions by separate close{} blocks. Method uncaughtException()
receives an object of type Throwable as an argument. Currently, to
handle different exceptions types separately, I use instanceof clause:

public class MyHandler implements Thread.UncaughtExceptionHandler {

public void uncaughtException(Thread t, Throwable e) {

if (e instanceof IllegalMatrixArgumentException) {

}
System.err.println(t + " threw exception: " + e);
}

 

[dgront]

Sorry, I accidentally submitted before finishing.

So I use instanceof to find out what kind of exception happened. This
looks tedious and I am looking for a more elegant solution. Do you
have any ideas?

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.

Dominik

 

[Eric Sosman]

Dear group,

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.

Now I plan to register a UncaughtExceptionHandler (my applications
runs always in a single thread) and to hide all the common code inside
uncaughtException() inherited from Thread.UncaughtExceptionHandler.

This works perfect, but a new problem appeared:

In typical try{} catch{} block I can handle different types of
exceptions by separate close{} blocks. Method uncaughtException()
receives an object of type Throwable as an argument. Currently, to
handle different exceptions types separately, I use instanceof clause:

public class MyHandler implements Thread.UncaughtExceptionHandler {

public void uncaughtException(Thread t, Throwable e) {

if (e instanceof IllegalMatrixArgumentException) {

}
System.err.println(t + " threw exception: " + e);
}

[... and then ...]

> Sorry, I accidentally submitted before finishing.
>
> So I use instanceof to find out what kind of exception happened. This
> looks tedious and I am looking for a more elegant solution. Do you
> have any ideas?
>
> 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.

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.

If you want to catch all exceptions in one of your
threads, just write a try/catch in the run() method:

public void run() {
try {
actualRun();
}
catch (IOException ex) {
...
}
catch (IncompleteAnnotationException ex) {
...
}
catch (ExceptionThatProvesTheRule ex) {
...
}
catch (Throwable t) {
...
}
}

.... where actualRun() is all the stuff that used to be
in run().

 

[Mike Schilling]

Dear group,

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.

Now I plan to register a UncaughtExceptionHandler (my applications
runs always in a single thread) and to hide all the common code inside
uncaughtException() inherited from Thread.UncaughtExceptionHandler.

This works perfect, but a new problem appeared:

In typical try{} catch{} block I can handle different types of
exceptions by separate close{} blocks. Method uncaughtException()
receives an object of type Throwable as an argument. Currently, to
handle different exceptions types separately, I use instanceof clause:

public class MyHandler implements Thread.UncaughtExceptionHandler {

public void uncaughtException(Thread t, Throwable e) {

if (e instanceof IllegalMatrixArgumentException) {

}
System.err.println(t + " threw exception: " + e);
}

public void uncaughtException(Thread t, Throwable e)
{
try
{
throw e;
}
catch (IllegalMatrixArgumentException ex)
{
...
}
etc.
}

 

[kleiton.contato]

Hey.. oyou should create another class for example:

public class IntegrationException extends Exception {

private Throwable rootCause;

public IntegrationException() {
super();
}

public IntegrationException(String message) {
super(message);
}

public IntegrationException(String message, Throwable cause) {
super(message, cause);
rootCause = cause;
}

public IntegrationException(Throwable cause) {
super(cause);
rootCause = cause;
}

public Throwable getRootCause() {
return rootCause;
}

public void setRootCause(Throwable throwable) {
rootCause = throwable;
}

}


when you find a block with try and catch you should change every
exception to IntegrationException .

like this:

public void doSomeThing()throws IntegrationException {
try{
// cod
}catch(Exception e){ // whatever exceptions
throw new IntegrationException(e);
}
}

with this way you throw every exception to IntegrationException.


bye

 

[Lew]

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.

 

[dgront]

Yes, I know it.

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.

Yes, I agree. If a bottom-level routine knows what to do, it does it.
I plan to use the trick with default handler only in a situation where
there is no possibility do continue the program. There is a part of my
code repeated in many places in many classes. The code is always the
same: it prints a message and quits. I want to have it in one copy.
For example to change the error message easily

Dominik

 

[Deepak Srivastava]

Lew is right.

We should always tend to throw exceptions for specific purpose and
they should be of specific types and need to be logged properly.
and if you think that piece of code is repeatedly used then you should
figure it out to make it generic and reusable.

--Deepak