geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Blewitt <>
Subject Re: [Error handling] NullPointer or IllegalArgument?
Date Thu, 14 Aug 2003 12:48:47 GMT
On Thursday, Aug 14, 2003, at 13:34 Europe/London, Greg Wilkins wrote:

> Jason Dillon wrote:
>>> [Exception] IllegalArgumentException: address must not be null
>> +1
>> org.apache.geronimo.common.NullArgumentException extends IAE and 
>> handles the formatting of the message too, so you can:
>> throw new NullArgumentException("address");
> I will only +1 the NullArgumentException if it is part of 
> internationalizing
> our Exception.  So that NullArgumentException can print out:

There is no reason why it couldn't be internationalised, like any other 
Exception type. Indeed, there's a static factory method 
NullArgumentException("fieldName",field) to do just that.

I guess this could be as easily internationalised as uses of the IAE 
messages, but has the advantage that they're all in one place :-)

> Other than that - I often find that subclassing exceptions just
> results it too extra hassle when too often most try blocks
> end with catch(Exception e) and you may as well just have
> one Exception type:
>   class ShitHappenedException extends Exception

True, but then that's bad client code as opposed to throwing specific 
types :-) But NAE is a subclass of IAE, so it's not expected to be 
caught on its own, just as part of a bad argument method (or more 
likely, RuntimeException.

I really think we ought to outlaw
try {

} catch(Exception e) {
// stuff

in the code -- it just eats too many exceptions that are desired (or at 
least, don't want to be hidden).

> But I think subclassing exceptions is good, if it is to add 
> functionality about throwing the exception (rather than catching it).

Bear in mind that as well as adding functionality, you're also 
subclassing the type. For example, EOFException is a subclass of 
IOException and adds no extra functionality, but it's a sufficiently 
common situation to be able to treat different exception types 
accordingly. When subclassing, you also subtype the superclass too ...

View raw message