On Tue, Sep 11, 2012 at 07:46:20AM +0200, Sébastien Brisard wrote: > 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...).
As I've already expressed in the past, I think that localization (as required by some of Luc's applications), as well as the more recent example of passing "null" to some constructors (as provided by Phil) are indeed to be considered as _outside_ the realm of CM: They are application requirements, pushed down to CM, that cannot be given a self-consistent rationale. When adding a feature to a library like CM, I think that it is very important (namely for long-term maintenance) that it does not rely on "out-of-band" information. I mean that the "Why does this feature exist?" should not need references to external-only requirements to be understandable. Of course, by "external-only" I mean that the feature's implementation could be changed just because the applications that use it changes. E.g. if the "TranslatorService", which I imagined in a previous post, existed, Luc's application could use it to fulfill its "Error messages should be displayed in French" requirement, and the localization of CM error messages could be removed from CM, without CM loosing anything. In that sense, the support of localization is not on the same footing as the support of "<some math algorithm>" because the latter is within the core business of CM, while the former is not. IMHO, the more a codebase grows, the less it should contain internal inconsistencies. Of course, we can conclude that now is not the right moment to clean up this or other defects of CM (e.g. because nobody has the time to do it, or to please people who have come to rely on the current state of affairs) but that is not making the issue go away. > So, if I understand correctly, NAE inheriting from NPE would mean no > error message. No. > In the present case, if we can't specify the index of > the faulty entry in the error message, You can: throw new NullArgumentException(LocalizedFormats.INDEX, i); > 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. Exactly. The _sole_ difference with the current NAE will be the change in the extends clause, from public class NullArgumentException extends MathIllegalArgumentException to public class NullArgumentException extends NullPointerException implements ExceptionContextProvider [And the "throw" statement above will be the same before and after this change.] > 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. They are not silly questions. It's precisely my point that such questions will arise (because of CM is lacking self-consistency). I'm pretty sure that none of us is familiar with being only on one side of the border; we all are also _users_ of CM and, quite often, the user's point-of-view is given the priority even if it leads to decisions that are sub-optimal in the longer term. Best regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
