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 ifThere may well be an argument for that.
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.
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 ...
