On 9/9/12 3:26 PM, Gilles Sadowski wrote: > On Sun, Sep 09, 2012 at 09:16:51AM -0700, Phil Steitz wrote: >> 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 [...] > For the reason I gave above: the inconsistent/non-existent policy will make > the issue recur sooner or later, as it happened now with Sébastien, as it > happened with me when I first signalled the burden of checked excpetions and > later when we agreed about MathRuntimeException, then changed again, to come > back again now, to where we were almost two years ago (IIRC)... > >> - 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? > The answer to that question is in the previous post. > >> We can leave the (needless, IMO) NullArgumentException as a subclass >> of MathIAE in place, or drop it and throw MathIAE directly in these >> cases. > "NullArgumentException" is about as needless as any subclass of "Exception" > or "RuntimeException". Either we use inheritance for what it's primarily > meant or we choose another, non-OO, language. > > This is going in circles; some people will drop from the discussion (or > already did) and some time from now, someone will "rediscover" this, among > other little defects of CM. These are worth correcting, but not worth > discussing endlessly. > > Let's just have all people here provide their preference and be done with > it. > > > Gilles > > P.S. Is there an occurrence in CM, where a method can be passed a null > argument?
Yes. One example is the constructor for EmpiricalDistribution that takes a RandomGenerator as argument. If a null is supplied, the constructor does not complain and the lazy initialization works as though the argumentless constructor had been used and a JDK random generator is created. There are other similar examples, mostly constructors, IIRC. Phil > > >> 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 >> > --------------------------------------------------------------------- > 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
