Hello, 2012/9/11 Gilles Sadowski <gil...@harfang.homelinux.org>: > On Mon, Sep 10, 2012 at 01:31:12PM -0700, Phil Steitz wrote: >> On 9/10/12 11:47 AM, Sébastien Brisard wrote: >> > Hi >> > What should I do there? >> > I'm trying to work on MATH-854. It turns out that FieldElement<T>.add >> > throws a NAE. Should I catch it below, and rethrow it with a more >> > detailed message (including the entry index)? >> >> IMO, yes. >> >> I would also check v itself and add to the javadoc contract that IAE >> is thrown if v is null. This is not consistently done in [math], >> though, and rarely in the linear package, so I am OK just letting >> the NPE propagate if v is null. It is a little awkward that v >> itself being null leads to NPE, but a component of it null leads to >> MIAE. > > Awkward? Of course it is; that's what I explained two posts ago. > > If we want to allow for the possibility of checking for null (and I agree > that it could be useful to pinpoint the problem by passing the information > about which index contains an invalid null entry), then we should adopt the > second option which I presented in that preceding post: > > "NullArgumentException" inherits from "NullPointerException" > > This really solves all issues (now that Luc has said that it is not a > problem if this one exception escapes the single-root hierarchy): It allows > to check for null in CM code and raise the same kind of exception that would > arise when no null check is performed. Both flexible and consistent. > I may be a bit slow, but I understood that localized error messages were an absolute requirement on Luc's side (which, BTW is good to know, I have always been wondering why we cared so much about localized error messages...). So, if I understand correctly, NAE inheriting from NPE would mean no error message. In the present case, if we can't specify the index of the faulty entry in the error message, I don't see the benefit of NAE over NPE. I must have missed something; I guess that NAE would inherit from NPE, AND implement ExceptionContextProvider, is that right? In that case, I like this solution. Sorry for polluting this thread with silly questions, but I am not used to writing programs for third-party end-users (I *AM* the end-user, or maybe my student enxt door), so I have to say I'm not familiar with the concerns raised in this thread.
Sébastien --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
