On 3/2/11 8:32 AM, Luc Maisonobe wrote: > Le 02/03/2011 12:37, Gilles Sadowski a écrit : >>> The recognised standard in the JDK is NPE on invalid null input. >>> >>> I have never overly liked this, but conform to it for JSR-310/ThreeTen. >>> >>> I use IAE in other projects which are higher up the stack. Whether >>> [math] is low or high level may determine the choice you make. >> I've always heard that CM is "low"-level; and this serves as the basis of >> many arguments (e.g. the "no-dependency" one). > Yes. > >> However I think that, in CM, the line between low- and high-level is blurred >> when some features are concerned (e.g. IMO localization does not belong in a >> low-level library). > It is a requirement for many libraries. In fact I even saw this > requirement being explicitly written in the specifications of an > official public Request For Proposal for a project concerning Apache > Commons Math. > >>> Personally, I don't use NullArgEx, as it is never an exception that >>> the user should catch. The message of IAE is sufficiently good to >>> remove the need for NullArgEx. Thus in my opinion, [math] would be >>> better off without NullArgEx (as it adds no real value). >> I guess that not everyone would agree with the "never". An application >> requirement might be that only a certain kind of exception is expected. >> Thus calls to CM are wrapped and every exception that comes out is turned >> into one of the "allowed" exceptions. >> I don't discuss whether it's good or bad programming style, I just mention >> that it happens. >> >>> However, with this, and other exception issues, the truth is that for >>> [math] its mostly a matter of taste. The value in [math] is in the >>> algorithms, not in whether the exceptions are any good or not. As >>> such, I would advise worrying less about exceptions, and more about >>> maths. If there is an exception decision, just try to follow the >>> modern JDK examples where possible (as it reduces discussion here). >> My viewpoint is that an exception is, in essence, a low-level object. It >> should just remain a very convenient way to communicate failure from a lower >> to upper layers of code. My revamping the CM's exceptions aimed at regaining >> the straightforward usage of standard exceptions (i.e. a direct call to >> "new" for constructing an exception that conveys the unadorned reason for >> the failure). >> The compromise we had reached was about keeping the localization feature, >> which in turn implied a departure from the standard exceptions in order to >> avoid code duplication. > Not really. Typically the 2.1 method > MathException.createNullPointerException (and the other similar ones) > did achieve using both the standard exception and the localization at > the same time. So I would say localization and exception hierarchy are > completely orthogonal features. > >> I consider this more important than using the >> standard exceptions hierarchy because, in CM, most exceptions are not >> recoverable anyway and they mainly serve by showing a failure message (i.e. >> at that point, whether an object is an instance of this or that class does >> not matter anymore). >> >> The discussion flared up when we started arguing on semantical issues that >> (IMHO) exceptions were not designed to handle and cannot enforce. I'm not >> going to re-state all the arguments once again; I'll simply quote you: >> "The value in [math] is in the algorithms, not in whether the exceptions >> are any good or not." >> I totally agree with the first statement, of course. > Fine! I think we all do agree on this. > >> The second part does >> not add (nor subtract) any value to it; it's unrelated. In my view, the >> exceptions are good if they allow to easily track down bugs (be they in CM >> or in user code). Accordingly they must precisely point to the source of the >> problem (in the code) and not try to outguess the user (as to what it >> should mean for him). > So can we try to conclude this part and go back to algorithms ? > > Rereading the past threads about this, including the advices from > non-math people, I would propose the following consensus : > > 1) use only unchecked exception > (i.e. confirm the switch started in trunk) +0 - move on > 2) keep localization +1 > 3) don't put all exceptions in a dedicated exception package > (but the general exceptions used everywhere could go there) +1 > 4) put specific exceptions in the package they are triggered > (for example ODE, linear ...) +1 > 5) use a small hierarchy backed by an implementation of the principle > of exception context as per [lang] to provide state information > and allow extension by users calling addValue(label, value), > a typical example could be one ConvergenceException class and > different labels/values for count exceeded or NaN/Infinity appearing Not sure exactly what is meant here. I don't think it is best to devolve all exception context into dynamic name/value pairs. I It is probably best to look at examples and base our decision on what is easiest to manage and understand. I am fine adding this to the arsenal and allowing users to use it to add more stuff to exceptions, but I need to see how it would work in examples before embarking on wholesale replacement.
Regarding the hierarchy, what I would like is a shallow but meaningful hierarchy of exception classes that encapsulate the kinds of things that fail in [math]. We have been talking about a few of them - iterative algorithms fail to converge, attempts at evaluating a function fail, input data or problem parameters violate preconditions, irrecoverable numerical problems occur... It would be great to think about these both at the top [math] level and in relation to the specific packages. Could be things are fine the way they are (trunk) or were (2.1). In any case, we need to decide what the hierarchy looks like. > 6) don't provide any top-level exception for errors occurring in > user-provided code (for solvers, ode, matrix visitors ...) but > ask them in documentation to use their own unchecked exception > that [math] will never see (i.e. remove FunctionEvaluationException, > DerivativeException, MatrixVisitorException) I agree with adding the concept of MathUserException, but I suspect there are internal uses and independent value in FunctionEvaluationException, DerivativeException and MatrixVisitorException. If the only uses we can ever see of these is for user code, then OK; but IIRC, we do use FunctionEvaluationException and DerivativeException internally. Is there a way that we can have it both ways? Still maintain these abstractions for use in [math] and by applications that use [math]; but still allow users to effectively propagate their own exceptions through the [math] API layers? > I'm not sure for NullPointer/NullArgument. Perhaps our own > NullArgumentException with the [lang] exception context principle would > be fine. I doubt we should check everything by ourselves (it would be a > real performance killer), so whatever we choose there will be untracked > NPE. We should check some arguments where it makes sense, which is what > we already do at some places. I agree that by and large, the null-checking in place now is adequate and going overboard will lead to performance issues. I also agree with what others have said that to some extent NPE is life in Java, so move on. I did prefer the 2.1 approach to creating RTEs, though. > Hoping to conclude this fast ... > Luc > >> >> 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
