Exception Exception is not compatible with throws clause in Runnable.run()

[Chris Miller]

Hi Folks,

I developing a proxy application, so threads seems like a good way to go.
In the early stages, I prefer to be inundated with stack traces so I can
judiciously decide what things will happen and which things I selectively
want to handle, so I can ignore/log the rest. To that end, I thought it
would be a good idea to catch and throw Exception, rather than one of the
many subclasses. When I tried to declare my run() method as:

public final void run() throws Exception

Eclipse complained:

Exception Exception is not compatible with throws clause in
Runnable.run()

I'm willing to take Eclipse at his word -- he's usually right, but I am
curious why this is the case, if anybody happens to know, and I'm also
interested in what I should declare as my class of exceptions so I can be a
general as I think I should.

Thanks for the help,

Chris.

 

[Chris Smith]

I developing a proxy application, so threads seems like a good way to go.
In the early stages, I prefer to be inundated with stack traces so I can
judiciously decide what things will happen and which things I selectively
want to handle, so I can ignore/log the rest. To that end, I thought it
would be a good idea to catch and throw Exception, rather than one of the
many subclasses. When I tried to declare my run() method as:

public final void run() throws Exception

Eclipse complained:

Exception Exception is not compatible with throws clause in
Runnable.run()

I'm willing to take Eclipse at his word -- he's usually right, but I am
curious why this is the case, if anybody happens to know, and I'm also
interested in what I should declare as my class of exceptions so I can be a
general as I think I should.

This is the case because if you propogate an exception out of run(),
Java has no idea what to do with it, so it picks a rather ugly option of
just printing a stack trace and ending the thread. Rather than do this
for you in the checked exception case and not even provide you with the
benefits of checked exceptions, run() is declared to not throw
Exception, and you're responsible for handling checked errors, at least,
in whatever way DOES make sense. If that default behavior is what you
want, it's easy enough to write:

try
{
...
}
catch (Exception e)
{
e.printStackTrace();
}

In my opinion, it would be a better idea to add a System.exit to the end
of that, but that's up to you.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Christophe Vanfleteren]

Hi Folks,

I developing a proxy application, so threads seems like a good way to go.
In the early stages, I prefer to be inundated with stack traces so I can
judiciously decide what things will happen and which things I selectively
want to handle, so I can ignore/log the rest. To that end, I thought it
would be a good idea to catch and throw Exception, rather than one of the
many subclasses. When I tried to declare my run() method as:

That's not a very good practice.
It would be better to throw subclasses of RuntimeException in such a case
instead of polluting every method signature with "throws Exception".
Or you could still throw regular (subclass of java.lang.Exception)
Exceptions, and still just have one "catch Exception" block.

Since all other Exceptions are subclasses of java.lang.Exception, just
catching Exception catches all subclasses.

You could then have code like this:

try{
//code that throws all kinds of exceptions
}catch(SomeSpecialException e) {
//handle it
}catch(Exception e) {
//handle other exceptions
}

You have to put the most specific Exceptions first in the catch block.

public final void run() throws Exception

Eclipse complained:

Exception Exception is not compatible with throws clause in
Runnable.run()

I'm willing to take Eclipse at his word -- he's usually right, but I am
curious why this is the case, if anybody happens to know, and I'm also
interested in what I should declare as my class of exceptions so I can be a
general as I think I should.

Thanks for the help,

Chris.

It's very simple:

void run() is defined in the Runnable interface (which the Thread class
also implements). The method is not defined to throw an Exception, so you
cant just add it to the method and still implement the Runnable interface.

You could throw a RuntimeException instead.

 

[Neil Green]

Chris Miller wrote:


try
{
...
}
catch (Exception e)
{
e.printStackTrace();
}

In my opinion, it would be a better idea to add a System.exit to the end
of that, but that's up to you.

In the case described, you think it would be best to terminate the
running application in the case of what could be a very short lived,
exceptional situation. Are you sure? For a server application (like a
proxy), it is probably not best to call System.exit( int ) but rather
dump as much context as you can to a log file and continue.

In answer to the original question. Runnable.run() is defined to throw
no checked exceptions, and so cannot be extended to throw a checked
exception. I would suggest considering what exceptions may be thrown
within the run method and handling them appropriately. Using a
run-and-see-what-exceptions are thrown approach works in prototyping,
but generally does not lead to robust, well designed code suitable for
production.

HTH
Neil

 

[Chris Smith]

In the case described, you think it would be best to terminate the
running application in the case of what could be a very short lived,
exceptional situation. Are you sure? For a server application (like a
proxy), it is probably not best to call System.exit( int ) but rather
dump as much context as you can to a log file and continue.

I was responding to the original question, which described a specific
goal: to run the program and get stack traces, so that they can be
handled by changing the code. With that goal, you want to most obvious
possible indication of an error. You don't want to write the exception
to a log and then just continue.

If this were production code, then I'd still recommend against trying to
continue without knowing what went wrong. If the exception means that
you couldn't retrieve someone's bank account balance, are you still
going to go ahead and add the deposit amount to a default value of 0,
and then store the result in the poor customer's bank account? Ignoring
exceptions is flat-out dangerous, even if you write a bunch of details
to a log. Sure, you could keep the server up for future requests in the
production case, but you certainly don't want to just log and continue.
You want to be sure you've terminated any kind of client state,
including ending the current request handling, and ending any kind of a
stateful session with that client.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation