Prev: Controlling content of text field
Next: Build A Home Internet Business For Extra Income Stream
From: markspace on 20 Mar 2010 17:09
Stefan Ram wrote:
> 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.


From: Christian Schulte on 20 Mar 2010 17:21
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.

In your example you explicitly test y != 0 before calling div(). If the
DivisionByZero exception is thrown although y != 0, the div() method is
broken and there is no way to handle that without fixing that method.
From: Tom Anderson on 20 Mar 2010 19:39
On Sat, 20 Mar 2010, Christian Schulte wrote:

> 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

--
Change happens with ball-flattening speed. -- Thomas Edison
From: Lew on 20 Mar 2010 20:02
Tom Anderson wrote:
> 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.

--
Lew
From: Arne Vajhøj on 20 Mar 2010 20:17
On 20-03-2010 16:33, Stefan Ram wrote:
> 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

 |  Next  |  Last
Pages: 1 2
Prev: Controlling content of text field
Next: Build A Home Internet Business For Extra Income Stream