Gilles Sadowski wrote: >>>> The added value that I see is that an IAE designating which argument >>>> that cannot be null is in fact null gives more specific information >>>> to the caller (or production support person examining logs) than >>>> just a propagated NPE. >>> Well, my initial post reported the inconsistency of throwing either NPE or >>> IAE as a result of checking for "null". If we take that NPE signifies a bug >>> in CM, then we can have the policy of throwing IAE when null is encountered >>> (and never explicitly throw NPE from CM). >>> >> +1 - that is what I meant by my option 1) above. > > This was your option 1: > >>> 1) remove NPE wrappers, propagating uwrapped NPEs where the code >>> wraps and rethrows NPE today. > > As I said, there are no wrappers around the NPE generated in CM. Either > "createNullPointerException" or "createIllegalArgumentException" is called > and they generate the corresponding exception (not wrapped within anything). > > What I propose (as an alternative the "simple" policy) above is to create > a "NullArgumentException" that inherits from "MathIllegalArgumentException". > This exception will be thrown whenever a null check fails (i.e. "null is an > illegal argument"). To be consistent, we should never throw NPE from CM. > Is that what you meant to agree with?
There may be some cases where it makes sense to propagate NPEs directly. I don't see any in the code now, but I would not rule it out for the future. I am fine, however, dispensing with MathRuntimeException.createNullPointerException (that's what I meant by "wrapped NPE." Technically, you are right, the resultant NPE is not really "wrapped," just specialized.) Where we throw IAE today with informative error message indicating which parameter was null, I want to retain the error message. Phil > > > Gilles > > --------------------------------------------------------------------- > 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
