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 14:04:35 GMT

On Thursday, Aug 14, 2003, at 14:19 Europe/London, Berin Loritsch wrote:

> Alex Blewitt wrote:
>> On Thursday, Aug 14, 2003, at 11:36 Europe/London, Jason Dillon wrote:
>>> I do not agree with the Exceptions section listed in the wiki.  I 
>>> think that a NPE can be thrown where appropriate.  For argument 
>>> methods which must not be null a NPE is not appropriate.  I think we 
>>> should change the text to make it clear that if you must throw an 
>>> NPE, then it is okay, but that you need to have a reason todo so and 
>>> that it must have a description.
>> I put that there to wean people away from the NPE re: discussions on 
>> this topic.
>> If you can give me a clear example of when throwing an NPE is 
>> desirable, please do so. But for every example you'll give, I'll ask 
>> why it couldn't be either an IllegalArgumentException (if it is to do 
>> with arguments), or if not a generic RuntimeException (with suitable 
>> messages).
> (Runs away screaming) NOOOOO!!!!
> NEVER throw a generic RuntimeException--it tells you nothing.  I am 
> currently
> maintaining a program that uses nothing but RuntimeExceptions, and 
> debugging
> the bugger is a serious pain in the arse.

It tells you more than a NullPointerException does. Consider: 
NullPointerException is generated automatically in the case of a code 
failure as you describe. Thus, if a NullPointerException is raised you 
can be sure that it comes from a null pointer error, and thus you know 
what kind of error to look for.

As soon as you start using NullPointerException to raise your own 
errors in the code, you lose that advantage. When an NPE occurs, you 
have to ask (a) Am I throwing that? or (b) Is the JVM throwing that? 
which can slow down the time taken to find and locate the bug.

On the other hand, a RuntimeException can be used as a generic 
something-has-gone-wrong-but-I-dont-have-a-specific-class-for-it, which 
therefore allows you to tell the difference between a true NPE and a 
failure event that the programmer would like to raise.

I feel sorry for you if you're maintaining code that /solely/ uses 
RuntimeExceptions, and I would agree that's a Bad Thing. Clearly, 
whenever there is a more appropriate exception (be it IAE or whatever) 
then that should be used instead, and if there's not a more suitable 
one then consider writing a new exception type.

> An exception should give you enough information to help you narrow 
> down where
> the bug originates.  Too many times the RuntimeException is caught far 
> too late
> to do anything useful with it.

Yes, in general, a checked exception will be better than an unchecked 
(e.g. RuntimeException)

> A typed exception works much better as you can make more specific 
> actions if
> necessary.  I am not saying to never extend a runtime exception, but I 
> am
> saying don't use it directly.  IMNSHO RuntimeException and Exception 
> should
> be abstract base classes and not concrete at all.

There may well be an argument for that.

In any case, I wasn't advocating 'Use RuntimeExceptions for all'. I was 
saying that there's never a reason to want to use NPE, and if you 
really need to throw an unchecked exception (for example, the interface 
doesn't allow it) then use a RuntimeException instead.

Correct me if I misunderstood your post, but it seemed that you assumed 
I was advocating RuntimeExceptions for everthing. I wasn't. 
RuntimeExceptions are pretty ugly and should be avoided where possible 
over another implementation or a checked exception (preferably).

What I was saying is that NPE is an exception a programmer should never 
throw, and if checked exceptions or other suitable exceptions (IAE, 
NAE) don't allow, then throw RuntimeException instead of NPE.


View raw message