Hi, 2012/9/10 Gilles Sadowski <gil...@harfang.homelinux.org>: > 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. > Since there is no way to enforce a strict policy on checking for null in CM, I think that NAE is useless, and should be droped. If we assume that every user of CM can use a debugger, then probably (and contrary to what I advocated earlier), checking early for null is also superfluous. I tend to document arguments which *can* be null (I think someone else also mentioned this practice), so that it's fairly safe (as someone already wrote) to assume that all other arguments *must* be non-null.
To sum up, I would favor complete removal of NAE. As for existing checks, I would either remove them, or throw an argumentless standard NPE. Phil was talking about loss of robustness. I don't think that CM as a whole is robust with respect to null pointers. In some places, the code fails in the standard way (NPE), while in others, it fails in a fully documented way. Since this is inconsistent, I don't think we should be afraid of losing robustness in the case of complete removal of existing checks for null. Again, I'm happy to keep them, but I'd rather throw a standard NPE in this case. Sébastien > > Gilles > > P.S. Is there an occurrence in CM, where a method can be passed a null > argument? > > >> >> 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
