Which exception to use here?

[Stefan Ram]

What would be a good (runtime-)exception class from the
standard library meaning »For reasons I do not understand,
a called submethod failed, and now I can't do my job.«

For example, method »m« calls »div«, and »div« might throw
a checked exception named »DivisionByZero«.

The client of »m« does not even know at all that »m« does a
division, so he should not get this exception, it would make
no sense to him. Therefore, one would like to repack it into
a (runttime-)exception that is intended to /make/ sense for
m's client, but one also believes that this exception will
never be thrown in the first place (and if it happens:
indicate a programmer error, not a runtime failure in the
sense of a harddisk device failure or so). So:

What would be a good class to use instead of
»WhatToUseHereException« below?

public void m()
{ ...

if( y != 0 )
{ try
{ q = div( x, y ); }
catch( final DivisionByZero divisionByZero )
{ throw new WhatToUseHereException( divisionByZero ); }}

... }

I believe, a runtime exception is more appropriate here than
a checked exception, but do not know which specific runtime
exception is best.

And is it better to try to use exception classes from Java SE
whenever possible when throwing new exceptions or to declare
additional exception classes for the code being written?

 

[markspace]

What would be a good (runtime-)exception class from the
standard library meaning »For reasons I do not understand,
a called submethod failed, and now I can't do my job.«

For example, method »m« calls »div«, and »div« might throw
a checked exception named »DivisionByZero«.

Well, in the specific case of division by zero, that's
java.lang.ArithmeticException. It's even mentioned in the class's docs.

And is it better to try to use exception classes from Java SE
whenever possible when throwing new exceptions or to declare
additional exception classes for the code being written?

I think it's better to make your own exception. Look at the docs for
the RuntimeException. There's a lot of packages which define their own
runtime exceptions. javax.xml.bind.TypeConstraintException, for
example, and javax.print.attribute.UnmodifiableSetException. Showing
that this idea is good practice, I believe.

The reason is that at some point you'll need to distinguish between your
own errors and those actually being thrown by the system, and it won't
be easy to guess which is which just based on the type of the exception.
Make your own exception, then you don't have to guess.

At minimum, just create one RuntimeException per package and use that
for all classes in that package.

package mypackage;
public class RuntimeExceptionWrapper extends RuntimeException {
public RuntimeExceptionWrapper( Throwable cause, String message ) {
super( cause, message );
}
}

is not much work. Then at least you can catch
mypackage.RuntimeExceptionWrapper to only catch those errors you
yourself throw.

 

[Tom Anderson]

Stefan Ram schrieb:
[...]

never be thrown in the first place (and if it happens:
indicate a programmer error, not a runtime failure in the
sense of a harddisk device failure or so). So:

What would be a good class to use instead of
?WhatToUseHereException? below?

java.lang.AssertionError probably if the div() method is specified to
_only_ throw the DivisionByZero exception for y == 0 and is never called
with y == 0 in the try block.

Yup. If you believe your code has done what's necessary to get a normal
return out of the submethod, then assert it - put an 'assert false' in the
catch block, or equivalently and better, a 'AssertionError e2 = new
AssertionError("impossible exception happened when dividing");
e2.initCause(e); throw e;'.

THe only trouble with this is that AssertionError is an Error, not a
RuntimeException, so a method which catches and deals with
RuntimeExceptions (eg by showing the user an error message and carrying
on) but not Errors won't deal with it.

If by 'programmer error' you mean an error on the part of the client of
the code you're writing, then an AssertionError isn't appropriate. If
the problem is a bad argument, then there's good old
IllegalArgumentException; if the problem is that your objects haven't been
set up right, then it's IllegalStateException. Other than those two, i
don't think there are any good general-purpose exceptions in the standard
library. Oh, NoSuchElement exception is useful sometimes. And
UnsupportedOperationException, but that's not appropriate here. I think
Mark is right - you probably need to define a new RuntimeException of your
own. Not sure what, though; naming exceptions can be very hard.

tom

 

[Lew]

If by 'programmer error' you mean an error on the part of the client of
the code you're writing, then an AssertionError isn't appropriate. If
the problem is a bad argument, then there's good old
IllegalArgumentException; if the problem is that your objects haven't
been set up right, then it's IllegalStateException. Other than those
two, i don't think there are any good general-purpose exceptions in the
standard library. Oh, NoSuchElement exception is useful sometimes. And
UnsupportedOperationException, but that's not appropriate here. I think
Mark is right - you probably need to define a new RuntimeException of
your own. Not sure what, though; naming exceptions can be very hard.

One typical approach is to use the project name. For example, for (fantasy)
website mousierestoration.com one might define a 'MousieException' (checked)
and a 'MousieRuntimeException' (unchecked), defining all four constructors for
each.

It's surprising how much mileage just having two custom exceptions can give.
I've worked on projects where there's a custom exception for every durn thing,
and it rapidly gets out of hand with little or no added benefit.

If you wrap the causal exception in the custom one's 'cause', log upon first
catch, and train all calling code to recognize the two app exceptions you have
pretty much all the control you need over exceptions.

 

[Arne Vajhøj]

What would be a good (runtime-)exception class from the
standard library meaning »For reasons I do not understand,
a called submethod failed, and now I can't do my job.«

For example, method »m« calls »div«, and »div« might throw
a checked exception named »DivisionByZero«.

The client of »m« does not even know at all that »m« does a
division, so he should not get this exception, it would make
no sense to him. Therefore, one would like to repack it into
a (runttime-)exception that is intended to /make/ sense for
m's client, but one also believes that this exception will
never be thrown in the first place (and if it happens:
indicate a programmer error, not a runtime failure in the
sense of a harddisk device failure or so). So:

What would be a good class to use instead of
»WhatToUseHereException« below?

public void m()
{ ...

if( y != 0 )
{ try
{ q = div( x, y ); }
catch( final DivisionByZero divisionByZero )
{ throw new WhatToUseHereException( divisionByZero ); }}

... }

I believe, a runtime exception is more appropriate here than
a checked exception, but do not know which specific runtime
exception is best.

And is it better to try to use exception classes from Java SE
whenever possible when throwing new exceptions or to declare
additional exception classes for the code being written?

I would go for a custom exception class extending
RuntimeException.

There does not seem to be any of the existing that fits
sufficient well.

Arne

 

[Arne Vajhøj]

One typical approach is to use the project name. For example, for
(fantasy) website mousierestoration.com one might define a
'MousieException' (checked) and a 'MousieRuntimeException' (unchecked),
defining all four constructors for each.

It's surprising how much mileage just having two custom exceptions can
give. I've worked on projects where there's a custom exception for every
durn thing, and it rapidly gets out of hand with little or no added
benefit.

I would suggest a per project base exception and sub exceptions.

Those that does not care about which it is just catch the base
exception and those that do care can catch sub exceptions.

I consider that the most flexible.

I would hesitate to use the "I don't care about what specific
exception it is now, so probably no one will ever want this"
logic.

I have seen SQLException.

Arne

 

[Jean-Baptiste Nizet]

Stefan Ram a écrit :

What would be a good (runtime-)exception class from the
standard library meaning »For reasons I do not understand,
a called submethod failed, and now I can't do my job.«

For example, method »m« calls »div«, and »div« might throw
a checked exception named »DivisionByZero«.

The client of »m« does not even know at all that »m« does a
division, so he should not get this exception, it would make
no sense to him. Therefore, one would like to repack it into
a (runttime-)exception that is intended to /make/ sense for
m's client, but one also believes that this exception will
never be thrown in the first place (and if it happens:
indicate a programmer error, not a runtime failure in the
sense of a harddisk device failure or so). So:

What would be a good class to use instead of
»WhatToUseHereException« below?

public void m()
{ ...

if( y != 0 )
{ try
{ q = div( x, y ); }
catch( final DivisionByZero divisionByZero )
{ throw new WhatToUseHereException( divisionByZero ); }}

... }

I believe, a runtime exception is more appropriate here than
a checked exception, but do not know which specific runtime
exception is best.

In previous projects, I simply used RuntimeException for these cases
(wrapping the original one). In my last toy project, I decided to go for
a more specific custom runtime exception named
ShouldNeverHappenException (still wrapping the original one).

JB.

 

[Roedy Green]

{ throw new WhatToUseHereException( divisionByZero ); }}

throw new IllegalArgumentException("km cannot be 0");
--
Roedy Green Canadian Mind Products
http://mindprod.com

Responsible Development is the style of development I aspire to now. It can be summarized by answering the question, “How would I develop if it were my money?” I’m amazed how many theoretical arguments evaporate when faced with this question.
~ Kent Beck (born: 1961 age: 49) , evangelist for extreme programming.