On 7 May 2014 21:07, "sebb" <seb...@gmail.com> wrote: > > On 7 May 2014 01:51, Paul Benedict <pbened...@apache.org> wrote: > > When you dereference a null pointer, you get an NPE. We can agree to that. > > We can also agree it's not inherently wrong to throw IAE on a null argument > > check, but this discussion has never been about that. The discussion has > > always centered on what the trend setters are doing -- and they say go with > > NPE. > > > > Oracle/Sun throws NPE in its method: > > http://docs.oracle.com/javase/7/docs/api/java/util/Objects.html#requireNonNull%28T%29 > > > > Google Guava throws NPE in its method: > > http://docs.guava-libraries.googlecode.com/git-history/release/javadoc/com/google/common/base/Preconditions.html#checkNotNull%28T%29 > > > > It's pretty clear where industry is going and not using NPE is not > > expected. We shouldn't try to resist where all the thought leaders in our > > industry are going. It doesn't make any sense. No matter what personal > > affinity/preference you have towards IAE, it's a losing battle because the > > march is going the other direction. > > None of that alters the fact the using NPE in this way is ambiguous. > Whereas IAE is not.
Yes but is this a discussion about what is correct or what we should do in Lang? I think the two are not necessarily the same (sadly) and that the focus is on the latter. Hence Paul's comment has merit. > > > Paul > > > > > > Cheers, > > Paul > > > > > > On Tue, May 6, 2014 at 6:27 PM, sebb <seb...@gmail.com> wrote: > > > >> On 6 May 2014 22:54, Paul Benedict <pbened...@apache.org> wrote: > >> > This is not a matter of law. If Oracle/Sun set a direction on how to use > >> > NPE, it's a really good idea to follow them -- even if you don't agree, > >> do > >> > it for the sake of consistency. I don't think using IAE is somehow > >> "better" > >> > Java than what they are doing. And I give weight to what Joshua said > >> > because he's a former architect of that company. Lang3 was designed to > >> > throw NPE on invalid null arguments because that's what the gurus, like > >> he, > >> > in our industry who publish "best practices" say it should. If your > >> opinion > >> > bears greater weight than those set forth the best practices, then you > >> win, > >> > but I don't advocate going back to IAE for nulls for the reasons stated. > >> > >> The problem is still that NPE can be thrown by the JVM for code bugs. > >> If you Google/Bing for "what does NPE mean?" most of the postings say > >> that this is due to a bug in the code that throws it rather than a bug > >> in the code that calls it. > >> > >> There is nothing inherently wrong with using IAE for reporting a null > >> argument. > >> I think it was a mistake to suggest using NPE for that. > >> One might as well throw ArithmeticException for a zero argument that > >> is going to be used as a divisor. > >> Neither is as helpful as IAE. > >> > >> The problem is that NPE is ambiguous. IAE is not. > >> > >> > > >> > > >> > > >> > Cheers, > >> > Paul > >> > > >> > > >> > On Tue, May 6, 2014 at 4:40 PM, Duncan Jones <dun...@wortharead.com> > >> wrote: > >> > > >> >> On 6 May 2014 22:27, "Michael Osipov" <1983-01...@gmx.net> wrote: > >> >> > > >> >> > Am 2014-05-06 15:27, schrieb Benedikt Ritter: > >> >> > > >> >> >> Hi Thiago, > >> >> >> > >> >> >> > >> >> >> 2014-05-06 14:53 GMT+02:00 Thiago Andrade <thia...@gmail.com>: > >> >> >> > >> >> >>> Hello people, > >> >> >>> > >> >> >>> Analizing the JIRA issue > >> >> https://issues.apache.org/jira/browse/LANG-1008the > >> >> >>> contributors noticed that NumberUtils.max/min methods all have the > >> same > >> >> >>> problem: > >> >> >>> They all throw an IllegalArgumentException when according to the > >> >> official > >> >> >>> documentation (Oracle|Sun) says that a NullPointerException must be > >> >> thrown > >> >> >>> when an argument must not be null. > >> >> >>> > >> >> >> > >> >> >> This is not a problem imho. It is a question of API design. I don't > >> now > >> >> an > >> >> >> offical documentation that say when IAE or NPE _must_ be thrown. > >> >> Sun/Oracle > >> >> >> at some point decided to throw NPE when ever a null reference is > >> passed > >> >> to > >> >> >> a method that doesn't accept null inputs. I don't feel this is right, > >> >> since > >> >> >> a null input is also an illegal argument. Why make a differenciation? > >> >> IMHO > >> >> >> NPE should be reserved to the JVM, when a method is called on a null > >> >> >> reference, but that's just my opinion. > >> >> > > >> >> > > >> >> > It *is* a problem because NullPointerException and > >> >> IllegalArgumentException have concrete semantics layed out in the JDK's > >> >> Javadocs. If you see how both are used in the JDK, you see that NPE and > >> IAE > >> >> are used properly and there is no such restriction to the JDK only. If > >> you > >> >> aread Effective Java, you'll see that you *have to* use NPE if a null > >> >> argument is passed. One might remember the NullArgumentException back in > >> >> Lang 2, it was removed because it is imperative to use NPE instead. > >> >> > >> >> Effective Java is a great book, but don't confuse Joshua's advice with > >> law. > >> >> > >> >> > > >> >> > Moreover, the Lang 3 package includes a great class, Validate, which > >> does > >> >> things right and now I can ask, why the hell is that not used throughout > >> >> the entire library? > >> >> > >> >> +1 to this. We should update all of lang to use Validate once we've > >> nailed > >> >> this issue. > >> >> > >> >> Duncan > >> >> > >> >> > > >> >> > > >> >> >>> However according to Apache Commons Lang Developer Guide, these > >> methods > >> >> are > >> >> >>> all correct. This guide says that "When throwing an exception to > >> >> indicate a > >> >> >>> bad argument, always try to throw IllegalArgumentException, even if > >> the > >> >> >>> argument was null. Do not throw NullPointerException.". > >> >> > > >> >> > > >> >> > Correct to the dev guide only -- not Java. > >> >> > > >> >> > > >> >> >> Since [lang] is currently designed this way, I'd rather deal with > >> this > >> >> >> issue for 4.0. We can then revisit our initial decision to only throw > >> >> IAE > >> >> >> an maybe align it to what the JDK now does. If you want to file an > >> >> issue, > >> >> >> my opinion is, that it should be fix version 4.0. Changing the > >> >> exceptions > >> >> >> that are thrown now may break clients (although I think there are > >> very > >> >> few > >> >> >> use cases where one should catch IAE or NPE). > >> >> > > >> >> > > >> >> > 4.0 has to use Validate throughout the entire package. NPE and IAE > >> >> indicate a programming error in the client not adhering to the contract > >> >> depicted by the Javadocs, so it is the client's problem to deal with > >> them. > >> >> With proper programming, you should not have to catch those exception at > >> >> all. > >> >> > > >> >> > > >> >> >>> This mail was sent in order to discuss around and make decisions to > >> >> solve > >> >> >>> this dilemma where the Java official specification says X and the > >> >> Apache > >> >> >>> official specification says Y. > >> >> >>> > >> >> >> > >> >> >> Can you please provide a lnk to the official specification you're > >> >> refering > >> >> >> to? ;-) > >> >> > > >> >> > > >> >> > Read Effective Java on exceptions. Thiago provided a URL in the JIRA > >> >> issue. > >> >> > > >> >> > Further good resources: > >> >> > > >> >> > 1. > >> >> > >> >> > >> http://docs.oracle.com/javase/7/docs/api/java/lang/NullPointerException.html > >> >> > 2. > >> >> > >> http://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html: > >> >> "One case where it is common practice to throw a RuntimeException is > >> when > >> >> the user calls a method incorrectly. For example, a method can check if > >> one > >> >> of its arguments is incorrectly null. If an argument is null, the method > >> >> might throw a NullPointerException, which is an unchecked exception." > >> >> > > >> >> > Michael > >> >> > > >> >> > > >> >> > > >> >> > --------------------------------------------------------------------- > >> >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> >> > For additional commands, e-mail: dev-h...@commons.apache.org > >> >> > > >> >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org >
