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
