On 9/9/12 4:34 AM, Gilles Sadowski wrote: > Hi. > > Further discussion on the JIRA page > https://issues.apache.org/jira/browse/MATH-856 > cannot reach a consensus on solving the issue that raised this thread. > > The proposal was that CM never checks for "null" and lets the JVM do it (and > thus throw the standard NPE). > > Phil wants to retain some null checks but opposes to throwing a NPE without > a "detailed message". > The localization mechanism being implemented in "ExceptionContext", we > cannot throw a standard NPE (since the error message won't be localized). > > For a consistent behaviour (as seen from the caller), we would have to > implement a subclass of the standard NPE: callers could do > > try { > // Call CM > } catch (NullPointerException e) { > // Handle NPE (raised by the JVM _or_ by CM). > } > > However, this breaks the consensus we arrived at (for v4.0) about CM > throwing only subclasses of "MathRuntimeExceprion" (singly rooted hierarchy). > > Phil proposes to throw MathIAE (IMO, it must be the specific > "NullArgumentException"), but this breaks the above use-case: Users have to > do > > try { > // Call CM > } catch (NullPointerException e) { > // Handle NPE (raised by the JVM). > } catch (NullArgumentException e) > // Handle NPE (raised by CM). > } > > showing blatantly that CM is not consistent: sometimes it lets a JVM > exception propagate, and sometimes it catches the problem eralier and throws > an exception that is not in the same hierarchy (NPE vs IAE or, in 4.0, > "MathRuntimeException"). > This is the current state of affairs, and I think that it is not > satisfactory. [As proven by this issue having recurred two or three times > already.] > > In light of this, I propose that either > * Phil changes his mind (no check for null performed in CM code), or > * we make an exception to the singly-rooted hierarchy just for > "NullArgumentException" (which, in 4.0, would become a subclass of the > standard NPE).
Why not just leave things alone - i.e., let some APIs document null handling and throw IAE at the point of method invocation when supplying a null violates the documented API contract? We can leave the (needless, IMO) NullArgumentException as a subclass of MathIAE in place, or drop it and throw MathIAE directly in these cases. Phil > > The second option cares for all the various positions _except_ the > singly-rooted hierarchy. > > > Regards, > 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
