Default exception handler

Thread view:

dgront - 26 Feb 2008 19:57 GMT

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);
}

Reply to this Message

dgront - 26 Feb 2008 20:03 GMT

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

Reply to this Message

kleiton.contato@gmail.com - 26 Feb 2008 20:39 GMT

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

> Sorry, I accidentally submitted before finishing.
>
[quoted text clipped - 11 lines]
>
> Dominik

Reply to this Message

Eric Sosman - 26 Feb 2008 20:34 GMT

> Dear group,
>
[quoted text clipped - 23 lines]
> System.err.println(t + " threw exception: " + e);
> }

[... and then ...]

> Sorry, I accidentally submitted before finishing.
>
[quoted text clipped - 9 lines]
> 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().

Signature

Eric.Sosman@sun.com

Reply to this Message

Lew - 26 Feb 2008 22:43 GMT

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
[quoted text clipped - 3 lines]
> > 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.

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.

Signature

Lew

Reply to this Message

dgront - 26 Feb 2008 23:09 GMT

> > 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

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

Reply to this Message

Deepak Srivastava - 27 Feb 2008 15:16 GMT

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

Reply to this Message

Mike Schilling - 26 Feb 2008 20:36 GMT

> Dear group,
>
[quoted text clipped - 23 lines]
> System.err.println(t + " threw exception: " + e);
> }

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

Reply to this Message

Default exception handler

Free Magazines