• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

IAE or NPE?

 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
i am having a hard time deciding if I should throw IllegalArgumentException or NullPointerException when a null parameter is passed into a method that does not accept null parameters. I looked inside some of Sun's classes, but they do both. The effect will be the same of course.

I'm so in the middle that I can't even start off the question with a position
 
Tony Morris
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
According to the J2SE API Specification, you must use NullPointerException for this case. I won't dig the reference up for you, since I'm lazy, but I also recall Bloch having something to say on the issue in Effective Java.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's not strictly a requirement in the API; rather it's something that you "should" do. "Applications should throw instances of this class to indicate other illegal uses of the null object." And Bloch says (p 176) that for an illegal null argument we should use NPE rather than IAE "by convention". Other java classes have been inconsistent on this (especially some of the older classes) but I would recommend using the NPE here as it does seem to be much more standard now, even if it's not strictly required.

I think that, if there weren't already an established convention on this, it would have been better to throw an IAE here. Maybe even have a new exception, NullArgumentException, which subclasses IllegalArgumentException since semantically a null argument is a specific type of illegal argument. (A standard NPE would still be used for the other wayt you might try to dereference a null, like using it to invoke an instance method.) But that's not the way Java usage has evolved, and at this point I think it's best to just stick to the NPE to mesh with most commonly accepted usage.
 
Tony Morris
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Excerpt from java.lang.NullPointerException:
"Thrown when an application attempts to use null in a case where an object is required."
That's good enough for me to make it mandatory.
Granted, English is implicitly defective as a language for specification of requirements, so what's "good enough" for me may not be "good enough" for you. Welcome to the J2SE API Specification
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Excerpt from IllegalArgumentException:

"Thrown to indicate that a method has been passed an illegal or inappropriate argument."

Either this or the quote you gave would be equally "good enough" for me on its own; unfortunately neither seems to clearly trump the other. Which is where "convention" comes in to resolve the matter, absent a clear directive IMO. Oh well - we're both used to seeing such ambiguities in the API and JLS, even though we often disagree on where they are or how exactly to resolve them. In this particular case I see more ambiguity than you do, but we do still seem to agree on the overall answer: prefer NPE to IAE for a null argument.
 
JuanP barbancho
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
IMO,

Use of NullPointerException is a bad choice.

I think that extends Thowable and not Exception, and It is the more complex Exception for programmer, When I see a NullPointerException I think that a not controled error is throw.

The best choice is to Extends IllegallArgumentException and Throw your extended exception.

Thanks.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
[Juan]: I think that extends Thowable and not Exception

Have you looked at the API for NullPointerException? Questions like this can be resolved by starting here and looking up the class in question. It may be ambiguous in some areas (as Tony and I were discussing); however it's very clear about the inheritance hierarchy.
 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks, I'll take this info under consideration.

In my other life where I develope automotive stuff there was a certain module that received a certain object. That object could be invalid or illegal. Illegal is something that should not happen. But laws are breakable, I guess Whereas invalid stuff was that which indicated brokeness. So i am trying to point out the difference between improper argument value vs. improper argument type.

I think NPE goes with improper type while IAE goes with improper value. type check is first, so maybe thats reason to use NPE.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I prefer IllegalArgumentExceptions in those cases, simply because it makes it more clear that it is a case that was explicitely checked for, and not an exception that was caused be dereferencing a null reference. That is, an IAE definitely indicates the wrong usage of a method, a NPE might as well be caused by an internal bug.
 
Rick O'Shay
Ranch Hand
Posts: 531
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
>> According to the J2SE API Specification, you must use NullPointerException for this case. I won't dig the reference up for you, since I'm lazy

There is no such specification and IMO that advice is counter-intuitive if not irrational. If the method is other than public you can certainly assert on the null condition.

In any case we have to first assume that the null value is invalid. Clearly that is not always the case. With that assumption in mind you should throw an IAE if you receive a null. NPE is thrown by the JVM when a reference resolves to a null pointer and attempts to access it. Throwing it is otherwise inappropriate.
 
Tony Morris
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Rick O'Shay:
>> According to the J2SE API Specification, you must use NullPointerException for this case. I won't dig the reference up for you, since I'm lazy

There is no such specification and IMO that advice is counter-intuitive if not irrational. If the method is other than public you can certainly assert on the null condition.

Don't tell me what there is no such thing as the J2SE API Specification, since that's great news for me; tell my employer, since they are paying me to do nothing if that is the case.

http://java.sun.com/j2se/1.5.0/docs/api/
JavaTM 2 Platform Standard Edition 5.0 API Specification

In any case we have to first assume that the null value is invalid. Clearly that is not always the case. With that assumption in mind you should throw an IAE if you receive a null. NPE is thrown by the JVM when a reference resolves to a null pointer and attempts to access it. Throwing it is otherwise inappropriate.


Who told you that? NPE is thrown by a JVM when a null reference is dereferenced, but is it restricted to that case? If so, since when? ...and why does the (imaginary) J2SE API Specification state otherwise? "Thrown when an application attempts to use null in a case where an object is required."

You might be referring to your own deeply held (mis)conceptions of reality, based on your own personal experiences, that do not coincide with the authoritative source, which in this case, is an ambiguous specification in English. Sometimes, I wish I could fantasise my own falsification of reality that suits my own agenda, but I have to concede, it is not a talent of mine.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rick, Tony, with all due respect, I think this would be more effective for all of us if you concentrated on dicussing content and intent, and tried to understand each other - instead of nitpicking words and fighting each other.

I'm quite sure that Tony didn't mean every method should throw a NPE when it gets a null parameter passed, and that Rick is aware of the Java Language Specification (or whatever you call it officially).

If you think that someone is wrong on a topic, you are free to ask questions to clarify misunderstandings or to provide your point of view for a counter balance without getting personal. Implying that someone's opinion is "irrational" or just a "deeply held misconception of reality" is far from being nice (I'd actually call it quite disrespectful) - and therefore not welcome at the Ranch. A far better reply to a post that you think of as plain dumb is to assume that you simply misunderstood it.

Please meditate about this. Thanks.
 
Michael Ernest
High Plains Drifter
Sheriff
Posts: 7292
Netbeans IDE VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What were the names of those two old guys in the balcony on the Muppet Show? I forget.
 
David O'Meara
Rancher
Posts: 13459
Android Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
:roll: Makes you wonder whether you are joining a conversation or spectating in a cat fight.

Originally posted by Ilja Preuss:
I prefer IllegalArgumentExceptions in those cases, simply because it makes it more clear that it is a case that was explicitely checked for, and not an exception that was caused be dereferencing a null reference. That is, an IAE definitely indicates the wrong usage of a method, a NPE might as well be caused by an internal bug.


I tend to do the same thing for the same reasons.
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Maybe even have a new exception, NullArgumentException, which subclasses IllegalArgumentException since semantically a null argument is a specific type of illegal argument.


Sounds like you want to be a part of creating Mustang. I'd submit that idea to Sun, and sign their agreement for contributing, and add it. I kind of like it.

Mark
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
OK, here's my comment. I get like that sometimes when I see a post in Hibernate that I feel is not accurate, I'll leave it at that. I want to just go and attack and assume things about the other person.

Then I stop, and think, how can I word this nicer. People will always have different opinions. Well, I think most of the time we are wrong, and there are few times we are right, and to realize this. Then we can first assume that we might be missing something, or that the question in question is subjective, and take a nicer approach.

I think the whole IAE or NPE is subjective to how you read the JLS and Javadocs. So I say we support Jim adding his new Exception to Mustang and move on.

Mark
 
Tony Morris
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ilja Preuss:
Rick, Tony, with all due respect, I think this would be more effective for all of us if you concentrated on dicussing content and intent, and tried to understand each other - instead of nitpicking words and fighting each other.

I'm quite sure that Tony didn't mean every method should throw a NPE when it gets a null parameter passed, and that Rick is aware of the Java Language Specification (or whatever you call it officially).

If you think that someone is wrong on a topic, you are free to ask questions to clarify misunderstandings or to provide your point of view for a counter balance without getting personal. Implying that someone's opinion is "irrational" or just a "deeply held misconception of reality" is far from being nice (I'd actually call it quite disrespectful) - and therefore not welcome at the Ranch. A far better reply to a post that you think of as plain dumb is to assume that you simply misunderstood it.

Please meditate about this. Thanks.


Sorry Ilja, I felt cornered in my response. I didn't mean to imply that Rick has provided an irrational response or a deeply held misconception of reality. Instead, I meant to portray that I have no other explanation for the response; I never rule out the possibility that there is something that I may not be understanding, hence why I posed it as a question. I expect a refutation to my speculation, or confirmation - no ego attacks intended. I have been wrong far more times than I have been right in the past, so of course, I expected a refutation.

In any case, I do indeed mandate that all methods that accept a reference type, fail immediately with NPE, except where a third party dependancy exists that prevents it. I gave a brief explanation here: http://www.coderanch.com/t/378117/java/java/null
 
Henry Wong
author
Marshal
Pie
Posts: 21446
84
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Michael Ernest:
What were the names of those two old guys in the balcony on the Muppet Show? I forget.


Waldolf and Astoria. They are named after an old landmark hotel here in New York City.

As for this question, if I was ask this by a colleague. My answer would have been "No real preference. I can live with either -- as long as it is *documented* ".

Henry

EDIT: I have just been informed by my wife, that I am incorrect about the muppets. Oh well... maybe someone else can give the correct answer.
[ November 05, 2005: Message edited by: Henry Wong ]
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tony, thanks for the clarification!
 
David O'Meara
Rancher
Posts: 13459
Android Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You get half points, Statler and Waldorf.
 
Brian Cole
Author
Ranch Hand
Posts: 908
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jim Yingst:
It's not strictly a requirement in the API; rather it's something that you "should" do. "Applications should throw instances of this class to indicate other illegal uses of the null object." And Bloch says (p 176) that for an illegal null argument we should use NPE rather than IAE "by convention". Other java classes have been inconsistent on this (especially some of the older classes) but I would recommend using the NPE here as it does seem to be much more standard now, even if it's not strictly required.

I think that, if there weren't already an established convention on this, it would have been better to throw an IAE here. Maybe even have a new exception, NullArgumentException, which subclasses IllegalArgumentException since semantically a null argument is a specific type of illegal argument. (A standard NPE would still be used for the other wayt you might try to dereference a null, like using it to invoke an instance method.) But that's not the way Java usage has evolved, and at this point I think it's best to just stick to the NPE to mesh with most commonly accepted usage.


Mr. Yingst has a better signal-to-noise ratio than most posts
in this thread, which is why I'm quoting it in its entirety
even though I'll refer to only parts of his post.

Anyway, I was unaware that anyone in authority had decreed that
one of NPE or IAE was preferred in this situation where we've
written a method that doesn't permit a null parameter but we
have detected one. And I agree that on first glance that an IAE
seems more appropriate. I begin to see the logic in choosing
NPE, though. Let me try to explain.

Suppose that before I add any error checking my method looks
like this:

But I want to make sure I throw the right thing when the parameter
is null. If we agree that it should be an IAE the code would look
like this:

On the other hand, if we agree that it should be a NPE, it could
look like this:

But IMHO this would be pointless. The only difference between that
and this
(does that look familiar?) is that if a NPE is thrown it will have
a detail message of "argument was null" instead of no details message,
which isn't much of a difference.

So if we decide that it NPE is correct, we can just dereference
our parameters as if they weren't null without having to write
any error-handling code and all will be well. But if we decide
that IAE is correct, we have to write a zillion null-checks.

Ah, the wisdom of choosing NPE begins to become apparent.

(I was going to elaborate on this a bit, but I think I'll save
it for later.)
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Brian Cole:
The only difference between that
and this
(does that look familiar?) is that if a NPE is thrown it will have
a detail message of "argument was null" instead of no details message,
which isn't much of a difference.


If this is an internal, non-published method, I agree. If it is a method that is published together with the source code, I probably still could live with it.

If it is a published method for which the source code isn't published, I'd very much prefer the explicite exception, though. If I call a method and get an anonymous NPE, I don't know what's wrong - wether I used the method incorrectly, or wether it's a bug in the method. That can make the difference between instantly knowing what went wrong and hours of debugging sessions. (This gets very much amplified when the method takes more than one parameter.)
 
Brian Cole
Author
Ranch Hand
Posts: 908
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well I think maybe it has more to do with how long/involved
the method is than how it was published. Consider

In some situations it might be nice if the exception detail message
tells us which parameter was null, but do you think it's a good idea
for a method this simple?

If so, why stop here? Should we go further and sometimes throw a
new ArithmeticException("divisor was zero") ? [Here again some might
argue it should be IllegalArgumentException("divisor was zero").]

To what extent are better detail messages worth the cost in added
runtime cycles? I'm not sure how I feel about these issues.

Regardless of what you think about exception detail messages, this
does give some insight into whether an IllegalArgumentException or
a NullPointerException should be thrown, don't you think?
 
Tony Morris
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is working around the fact that the exception has not been documented.
One way is to declare it in a throws clause, or you could prefer an annotation (I won't go into why).

In any case, given a method:

You know exactly when a NPE is thrown, when o1 is null or o2 is null. There is no guessing. If the method throws a NPE when neither o1 or o2 are null, then the method implementation is defective and is in violation of its contract. It is unfortunate that this requirement must be specified in English, and is not available formally at compile-time for enforcement. Maybe a language like this may exist some day

At least that the method may throw a NPE is available through reflection because of the throws clause (or annotation).
 
JuanP barbancho
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
IMO, You must create your customized exception, I think that NullPointerException and IllegalArgumentException, both are Spec Exception, If you throw a Exception you could extend, any of this exception.
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24212
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by JuanP barbancho:
You must create your customized exception


No.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

You know exactly when a NPE is thrown, when o1 is null or o2 is null. There is no guessing.
<hr></blockquote>

Besides the fact that comments can lie.

And that at runtime the comment doesn't tell you wether o1 or o2 was null. But that's of course orthogonal to the NPE vs. IAE question.

If the method throws a NPE when neither o1 or o2 are null, then the method implementation is defective and is in violation of its contract. It is unfortunate that this requirement must be specified in English, and is not available formally at compile-time for enforcement. Maybe a language like this may exist some day


Well, of course this can be specified in code in Eiffel, or with DBC enhancements in Java. But those are then only checked at runtime.

Nice, on the other hand, has syntax to declare the non-nullness of a reference, and the compiler can enforce that! Not sure wether that's what you were looking for, though: http://nice.sf.net/
[ November 07, 2005: Message edited by: Ilja Preuss ]
 
Tony Morris
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ilja Preuss:

You know exactly when a NPE is thrown, when o1 is null or o2 is null. There is no guessing.
<hr></blockquote>
Besides the fact that comments can lie.

And that at runtime the comment doesn't tell you wether o1 or o2 was null. But that's of course orthogonal to the NPE vs. IAE question.



Well, of course this can be specified in code in Eiffel, or with DBC enhancements in Java. But those are then only checked at runtime.

Nice, on the other hand, has syntax to declare the non-nullness of a reference, and the compiler can enforce that! Not sure wether that's what you were looking for, though: http://nice.sf.net/

[ November 07, 2005: Message edited by: Ilja Preuss ]


Comments can lie indeed, which is unfortunate. Is there an issue with the comment, or the implementation? Assert the correctness of the requirement (the comment) before extrapolating to the implementation of requirement. That it can only be enforced at runtime is not quite true. Java enforces many contracts at compile-time. For example, if you were to implement the I interface, you would be forced by the compiler to implement a method, called 'm', with parameters, etc. etc. Specifying a compile-time enforceable contract has been prototyped successfully.

Nice is nicer, but not nicest, at least, to me 'Non-nullness' metadata is better, but not best. It accomplishes one outstanding issue (of Java) - that you cannot enforce "non-nullness" at compile-time, without third party support. There is another outstanding issue that invalidates the very existance of null itself; that 'null' (the concept) is a direct contradiction of the objectives of a type-safe language. It is akin to allowing integer literal values up to an including 2^31-1, except for the value 72, simply because 72 is a special case (for whatever reason), just like 'null' is a special case. That it is a more difficult problem to solve (putting 72 into the integer literal set is simple to solve) doesn't make it less of a special case.

You could of course, change your objectives, "Java/Nice/whatever is a type-safe language, with the exception of nullable references", in which case, one would have to analyse the practically of such an objective, versus the simpler objective of "Java/Nice/whatever is a type-safe language".

This is why (I believe) it's important to acknowledge the deficiences of Java. For example, given my definition of a "type-safe language", that I'm assuming we all agree on, Java is not type-safe at all. In fact, it possesses one (and many more) contradictions of this definition, null. I see no other option, other than to redefine "type-safety" or concede that Java is not type-safe. Redefining "type-safety" in this case, is just a romantic exercise to suit my agenda (of simplicity in the name of "the need for less thinking"), but not a derivation of reality. That's not to say that all redefinitions are this way of course.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tony, I didn't mean to say that it's not possible to enforce contracts at compile time, only that neither Java nor Eiffel can do it for non-nullness.

Regarding type-safety, I don't think that this is a property that a language either has or doesn't have - it's a continuum. There are certainly languages that are more type-safe than Java, but there are also a lot that are less. It might even be the case that type-safety needs to be balanced against other properties of a language, that "total type-safety" would come at a cost that some people wouldn't like to pay.
 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ilja Preuss:
...It might even be the case that type-safety needs to be balanced against other properties of a language, that "total type-safety" would come at a cost that some people wouldn't like to pay.




Is null an argument?
 
Tony Morris
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Do you mean, does it even exist as something that can be argued about?
I've heard various philosophies, mathematical explanations, etc.
I'm undecided.

In any case, the keyword itself surely exists
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic