How often do you really want to catch these? Matt
On Fri, Aug 30, 2013 at 1:20 PM, Gary Gregory <garydgreg...@gmail.com>wrote: > Another perspective to think about is whether you want to write code like: > > try { > // la-di-da > } catch (NullPointerException e) { > // garbage in! > } > > or: > > try { > // doo-wap-doo-wap > } catch (IllegalArugumentException e) { > // garbage in! > } > > Catching NPE just smells funny to me. > > Gary > > > > On Fri, Aug 30, 2013 at 1:06 PM, sebb <seb...@gmail.com> wrote: > > > The fact that NPE is documented in Bloch is quite important. > > > > Whatever we do choose, we should make sure to document all th reasons > > (pros and cons) somewhere other than just the mailing list! > > > > On 30 August 2013 17:30, Matt Benson <gudnabr...@gmail.com> wrote: > > > The discussion for [lang], none of whose participants have weighed in > > here, > > > took place in late 2009 (so perhaps a little longer ago than I thought) > > and > > > is archived at [1]. IMO Paul B. makes some pretty compelling arguments > > in > > > [2]. > > > > > > Matt > > > > > > [1] http://markmail.org/thread/7gw7xzrc3c3ul74c > > > [2] http://markmail.org/message/wmc4jh4pmhjjtxdf > > > > > > > > > On Fri, Aug 30, 2013 at 11:13 AM, sebb <seb...@gmail.com> wrote: > > > > > >> The JDK Javadoc says of NPE: > > >> > > >> * Applications should throw instances of this class to indicate > > >> * other illegal uses of the <code>null</code> object. > > >> > > >> and of IAE: > > >> > > >> * Thrown to indicate that a method has been passed an illegal or > > >> * inappropriate argument. > > >> > > >> That says to me that we should throw IAE here. > > >> > > >> The JDK does use NPE for parameter checks, but it also uses IAE, for > > >> example: > > >> > > >> javax.management.monitor.Monitor.addObservedObject > > >> java.rmi.activation.ActivationDesc.ActivationDesc > > >> javax.management.relation.RoleList.add > > >> javax.imageio.metadata.IIOMetadataFormatImpl.addAttribute > > >> > > >> On 30 August 2013 16:50, Adrian Crum < > > adrian.c...@sandglass-software.com> > > >> wrote: > > >> > I've seen a lot of discussions on NPE versus IAE, and in the end > they > > all > > >> > condense down to what Matt stated here: Those who favor NPE cite the > > JDK > > >> > classes as a pattern to follow, and those who favor IAE say it is a > > >> better > > >> > description of the problem. From my perspective, both are valid > > >> viewpoints, > > >> > and a project simply needs to choose one. In the end, the choice is > > >> neither > > >> > "right" nor "wrong" - it is just a choice. > > >> > > > >> > -Adrian > > >> > > > >> > > > >> > > > >> > On 8/30/2013 8:07 AM, Matt Benson wrote: > > >> >> > > >> >> Let me stir the pot: > > >> >> At a fundamental level I agree that a required *argument* should > > >> throw > > >> >> an > > >> >> IllegalArgumentException when null is supplied. However, ISTR the > > >> >> decision > > >> >> to do otherwise in [lang] having been discussed on-list in the > > >> >> not-so-distant past, and the result of that discussion being that > > NPE is > > >> >> usually the result in the core JDK classes. So I wouldn't > > characterize > > >> >> the > > >> >> situation as "[lang] *just happens* to throw NPE." Now, [lang] is > > in a > > >> >> slightly unique situation as its stated mission is to complement > Java > > >> SE, > > >> >> so it could be argued that [lang] is under greater pressure to > > conform > > >> for > > >> >> that reason. But my personal preference, in light of the standing > > >> >> decision > > >> >> with [lang], would be for consistency throughout Commons components > > >> >> *despite* the fact that at a purely semantic level I agree with the > > >> >> arguments in favor of IllegalArgumentException. > > >> >> > > >> >> To summarize, +1 for NullPointerException from me. > > >> >> > > >> >> Matt > > >> >> > > >> >> > > >> >> On Fri, Aug 30, 2013 at 9:36 AM, Benedikt Ritter < > brit...@apache.org > > > > > >> >> wrote: > > >> >> > > >> >>> 2013/8/30 sebb <seb...@gmail.com> > > >> >>> > > >> >>>> On 30 August 2013 15:19, Benedikt Ritter <brit...@apache.org> > > wrote: > > >> >>>>> > > >> >>>>> I've removed the generics in r1518974, thanks for spotting that > > sebb. > > >> >>>>> > > >> >>>>> Regarding the exception to throw I'm indifferent. The important > > thing > > >> >>> > > >> >>> is > > >> >>>> > > >> >>>> to > > >> >>>>> > > >> >>>>> fail early. > > >> >>>>> > > >> >>>> ... and with a helpful message. > > >> >>>> > > >> >>>>> I personally thing that NPE should be reserved for signaling > that > > >> some > > >> >>>> > > >> >>>> code > > >> >>>>> > > >> >>>>> tried to invoke a method on a null reference. > > >> >>>> > > >> >>>> +1 > > >> >>>> > > >> >>>>> In our case null is illegal because we know that some code later > > on > > >> >>> > > >> >>> would > > >> >>>>> > > >> >>>>> break if we accept a null reference. So IllegalStateException > > makes > > >> >>>> > > >> >>>> sense. > > >> >>>> > > >> >>>> s/IllegalStateException /IllegalArgumentException/ > > >> >>>> > > >> >>>> +1 > > >> >>>> > > >> >>> Sorry, I meant IAE of corse. > > >> >>> > > >> >>> > > >> >>>>> Imaging having a method that accepts an int and only positive > ints > > >> are > > >> >>>>> valid. You would throw an IllegalArgumentException if a negative > > int > > >> is > > >> >>>>> passed to that method and not a NegativeIntegerException (or > what > > >> >>> > > >> >>> ever). > > >> >>>>> > > >> >>>>> But James has a point. If [LANG] uses NPE maybe we should stick > to > > >> >>> > > >> >>> this. > > >> >>>> > > >> >>>> I don't think we have to do the same as LANG, so long as the > > Javadoc > > >> is > > >> >>>> clear. > > >> >>>> > > >> >>>>> Feel free to change it. I'll leave it for now since there > doesn't > > >> seem > > >> >>> > > >> >>> to > > >> >>>>> > > >> >>>>> be consensus?! > > >> >>>> > > >> >>>> Unless there are other reasons than "LANG happens to use NPE" I > > think > > >> >>>> we should stick with IAE, as it more clearly indicates the the > > problem > > >> >>>> is not within the method throwing it. > > >> >>>> > > >> >>>> The problem with using NPE to flag parameter errors is that it > > >> >>>> confuses the user as to the likely cause. > > >> >>>> > > >> >>>> Leave NPEs to the runtime system. > > >> >>>> > > >> >>> agreed. > > >> >>> > > >> >>> > > >> >>>>> Benedikt > > >> >>>>> > > >> >>>>> > > >> >>>>> 2013/8/30 James Carman <ja...@carmanconsulting.com> > > >> >>>>> > > >> >>>>>> Well, the problem with using NPE is that we as Java developers > > have > > >> >>>>>> learned through the years that NPE typically is an "oh crap" > > >> >>>>>> situation, where something is terribly wrong (we hate seeing > > those). > > >> >>>>>> Thus, our users may have knee-jerk reactions and not even know > to > > >> >>>>>> inspect the message for the real cause. IAE is less alarming, > > IMHO. > > >> >>>>>> Just my $0.02, but we've been doing it that way for a long time > > in > > >> >>>>>> [lang], so be it. > > >> >>>>>> > > >> >>>>>> > > >> >>>>>> On Fri, Aug 30, 2013 at 9:01 AM, sebb <seb...@gmail.com> > wrote: > > >> >>>>>>> > > >> >>>>>>> AFAIK "accidental" NPEs don't have a message associated with > > them. > > >> >>>>>>> > > >> >>>>>>> So provided that the assertion generates the NPE with a > suitable > > >> >>>>>>> message (e.g.as currently done for the IAE) then it *should* > be > > >> >>>>>>> possible for the end user to distinguish the two cases. > > >> >>>>>>> > > >> >>>>>>> I am slightly in favour of retaining IAE as the cause is > obvious > > >> >>> > > >> >>> with > > >> >>>>>>> > > >> >>>>>>> needing to look at the NPE message. > > >> >>>>>>> > > >> >>>>>>> == > > >> >>>>>>> > > >> >>>>>>> Horrible hack: - if you want to use NPE, you could wrap an IAE > > in > > >> >>> > > >> >>> the > > >> >>>>>> > > >> >>>>>> NPE: > > >> >>>>>>> > > >> >>>>>>> npe = new NPE(msg); > > >> >>>>>>> npe.initCause(new IAE(msg)); > > >> >>>>>>> throw npe; > > >> >>>>>>> > > >> >>>>>>> Or vice-vera, of course! > > >> >>>>>>> > > >> >>>>>>> Not sure that gains anything, but it does make the stack trace > > look > > >> >>>>>>> more impressive! > > >> >>>>>>> > > >> >>>>>>> On 30 August 2013 13:42, James Carman < > > ja...@carmanconsulting.com> > > >> >>>>>> > > >> >>>>>> wrote: > > >> >>>>>>>> > > >> >>>>>>>> Commons Lang's Validate.notNull() throws NPEs. I don't know > > that > > >> >>>> > > >> >>>> I've > > >> >>>>>>>> > > >> >>>>>>>> necessarily agreed with that, but at some point a decision > was > > >> made > > >> >>>>>>>> that null constraint violations should throw NPEs. Food for > > >> >>> > > >> >>> thought. > > >> >>>>>>>> > > >> >>>>>>>> On Fri, Aug 30, 2013 at 8:32 AM, Gary Gregory < > > >> >>>> > > >> >>>> garydgreg...@gmail.com> > > >> >>>>>> > > >> >>>>>> wrote: > > >> >>>>>>>>> > > >> >>>>>>>>> On Fri, Aug 30, 2013 at 8:25 AM, Emmanuel Bourg < > > >> >>> > > >> >>> ebo...@apache.org> > > >> >>>>>> > > >> >>>>>> wrote: > > >> >>>>>>>>>>>> > > >> >>>>>>>>>>>> + if (parameter == null) { > > >> >>>>>>>>>>>> + throw new > IllegalArgumentException("Parameter > > '" > > >> >>> > > >> >>> + > > >> >>>>>>>>>> > > >> >>>>>>>>>> parameterName + "' must not be null!"); > > >> >>>>>>>>>>>> > > >> >>>>>>>>>>>> + } > > >> >>>>>>>>>>>> + } > > >> >>>>>>>>>>>> +} > > >> >>>>>>>>>> > > >> >>>>>>>>>> Isn't a null value supposed to throw a NPE ? > > >> >>>>>>>>>> > > >> >>>>>>>>> Not always IMO. When I see an NPE I assume something is very > > >> wrong > > >> >>>> > > >> >>>> and > > >> >>>>>> > > >> >>>>>> that > > >> >>>>>>>>> > > >> >>>>>>>>> it could be a bug in the impl OR a call site, somewhere on > the > > >> >>> > > >> >>> code > > >> >>>>>> > > >> >>>>>> path. > > >> >>>>>>>>> > > >> >>>>>>>>> With an IAE, I know for sure it's a problem in the call site > > >> >>> > > >> >>> (which > > >> >>>>>> > > >> >>>>>> could > > >> >>>>>>>>> > > >> >>>>>>>>> be a bug of course). > > >> >>>>>>>>> > > >> >>>>>>>>> I does not help that the JRE/JDK is inconsistent, so it's > > hard to > > >> >>>> > > >> >>>> find > > >> >>>>>>>>> > > >> >>>>>>>>> examples. > > >> >>>>>>>>> > > >> >>>>>>>>> Gary > > >> >>>>>>>>> > > >> >>>>>>>>> > > >> >>>>>>>>>> Emmanuel Bourg > > >> >>>>>>>>>> > > >> >>>>>>>>>> > > >> >>>>>>>>>> > > >> >>>> > > --------------------------------------------------------------------- > > >> >>>>>>>>>> > > >> >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > >> >>>>>>>>>> For additional commands, e-mail: > dev-h...@commons.apache.org > > >> >>>>>>>>>> > > >> >>>>>>>>>> > > >> >>>>>>>>> > > >> >>>>>>>>> -- > > >> >>>>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > > >> >>>>>>>>> Java Persistence with Hibernate, Second Edition< > > >> >>>>>> > > >> >>>>>> http://www.manning.com/bauer3/> > > >> >>>>>>>>> > > >> >>>>>>>>> JUnit in Action, Second Edition < > > >> http://www.manning.com/tahchiev/ > > >> >>>>>>>>> Spring Batch in Action <http://www.manning.com/templier/> > > >> >>>>>>>>> Blog: http://garygregory.wordpress.com > > >> >>>>>>>>> Home: http://garygregory.com/ > > >> >>>>>>>>> Tweet! http://twitter.com/GaryGregory > > >> >>>>>>>> > > >> >>>>>>>> > > >> >>> > > --------------------------------------------------------------------- > > >> >>>>>>>> > > >> >>>>>>>> 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 > > >> >>>>>> > > >> >>>>>> > > >> >>>>> > > >> >>>>> -- > > >> >>>>> http://people.apache.org/~britter/ > > >> >>>>> http://www.systemoutprintln.de/ > > >> >>>>> http://twitter.com/BenediktRitter > > >> >>>>> http://github.com/britter > > >> >>>> > > >> >>>> > > --------------------------------------------------------------------- > > >> >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > >> >>>> For additional commands, e-mail: dev-h...@commons.apache.org > > >> >>>> > > >> >>>> > > >> >>> > > >> >>> -- > > >> >>> http://people.apache.org/~britter/ > > >> >>> http://www.systemoutprintln.de/ > > >> >>> http://twitter.com/BenediktRitter > > >> >>> http://github.com/britter > > >> >>> > > >> > > > >> > > > >> > > --------------------------------------------------------------------- > > >> > 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 > > > > > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > Java Persistence with Hibernate, Second Edition< > http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory >