Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: geronimo-dev@incubator.apache.org
Date: Thu, 14 Aug 2003 17:31:52 +0100
Subject: Re: [Error handling] NullPointer or IllegalArgument?
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
From: Alex Blewitt <Alex.Blewitt@ioshq.com>
To: geronimo-dev@incubator.apache.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <3F3B9C16.4000205@apache.org>
Message-Id: <CF81A1BD-CE74-11D7-A6C3-0003934D3EA4@ioshq.com>

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

> Alex Blewitt wrote:
>
> <snip/>
>
>>> 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.
>
> Actually, I would much rather see an NPE with a message (you can 
> include
> the name of the parameter in the message) than a generic 
> RuntimeException.

It may not always be easy to test between an NPE that you've raised, 
versus one that a VM has raised. For example, if there are automated 
tests and there's an NPE, that (to me) always means program bug.

> The only time an NPE gives you insufficient information is when it is
> automatically generated--there is no message to clue you in.

This is a way of detecting between an automatically raised NPE and a 
'manually' raised NPE, but not something you can simply do with a catch.

> If you are adamately opposed to NPEs, then IAE 
> (IllegalArgumentExceptions)
> are a nice alternative.  Either IMO are far better than generic
> RuntimeExceptions.

I had a long discussion about Exceptions (good and bad) and the 
conclusion we came up with was: possibly. Actually, there is a time 
when a RuntimeException is good; when you've got a method that can't 
add extra checked exception types to, and you need to throw one in your 
code:

public class Super {
   public void methodNoEx() { (*)
   }
}

pubic class Sub extends Super {
   public void methodNoExt() /* cannot throw antying else */
   {
     //
    try {
       io.read(buffer);
    } catch (IOException e) {
       throw new RuntimeException(e);
     }
}

But if you agree not to throw NPEs and use other types, then I'll agree 
not to throw generic RuntimeExceptions. Sounds like a good compromise 
to me :-)

Alex.

(*) Yes, you could argue that it's a bad API, and that IOException 
should be added to the throws clause. But particularly, when you're 
dealing with an interface (e.g. java.util.Iterator) or an abstract 
super-type (java.util.AbstractTreeModel) you don't often have the 
ability to change the supertype method definition ...