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.
Alex.
