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)
2) keep localization
3) don't put all exceptions in a dedicated exception package
(but the general exceptions used everywhere could go there)
4) put specific exceptions in the package they are triggered
(for example ODE, linear ...)
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
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'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.
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
