commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <Luc.Maison...@free.fr>
Subject Re: [Math - 403] Never propagate a "NullPointerException" resulting from bad usage of the API
Date Fri, 04 Mar 2011 11:01:14 GMT
Le 03/03/2011 23:51, Gilles Sadowski a écrit :
> Hi.
> 
>>>> SingularMatrixException, NonSymmetricMatrixException and the likes are
>>>> really tightly bound to linear algebra and could be in the linear
>>>> package where they are triggered. They could appear in the signatures of
>>>> algorithms in other package that do call linear algebra, but this is not
>>>> sufficient to put them in a general package.
>>>
>>> Yes, the "...MatrixException" classes are the borderline case (meaning that,
>>> if they were the majority of exception classes, I'd prefer to see them in
>>> the "linear" package). However, I argue that when there exists an
>>> "exception" to contain the general exceptions, then it is clearer to have
>>> them all there.
>>> Moreover "NonPositiveDefiniteMatrixException" is already a counter-example
>>> as it is used in "linear" and in "random".
>>
>> It is used in random because the classes in the random package do use
>> the linear package to perform a Cholesky decomposition, which triggers
>> the exception. This is an example of the last sentence in my rationale
>> above. This appearance is not sufficient to put the exception out of linear.
> 
> The class "CorrelatedRandomVectorGenerator" does not use the
> "CholeskyDecomposition" from package "linear"; it has its own "decompose"
> method which explicitly throws "NonPositiveDefiniteMatrixException"
> instances (at lines 214 and 222).

Right. I did not remember that (despite I wrote this code).

> 
>>> Since we probably won't have much more exception classes than there are now
>>> (31 out of which less than 10 are probably candidates for relocation in
>>> their main use package), it is fairly manageable and it will be more stable.
>>
>> Let's wait for the opinions of other people and decide upon that.
>>
>>>
>>>>>
>>>>>>  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
>>>>>
>>>>> -1 for removing any of the new exceptions (except "NullArgumentException"):
>>>>>    The hierarchy in trunk is shallow and small.
>>>>>
>>>>> +0 for implementing the map feature.
>>>>>    Do you mean it as replacement of the "general" and "specific" message
>>>>>    pattern (i.e. CM would use this feature) or as a user-only feature?
>>>>
>>>> I was thinking at both replacing the general and specific features and
>>>> letting users call it in case they want to add their own stuff.
>>>
>>> I'll create a JIRA issue for the new "map" feature, to discuss the details
>>> of the functionality.
>>
>> Fine, but discussion is easier on the list (with a dedicated thread), we
>> can open the Jira issue once we have decided what to do.
> 
> I propose to extend the "MathThrowable" interface with methods declarations
> similar to what is done in [Lang] and implement the functionality in
> "MathRuntimeException". [While looking at it, I notice that [Lang] has
> a dedicated "exception" package...]

Fine.

> 
>>>
>>>>>
>>>>>>  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)
>>>>>
>>>>> +1 for removing all exceptions for which there doesn't exist any "throw"
>>>>>    statement within CM. And also "MathUserException" (the few uses of
it in
>>>>>    trunk should be replaced).
>>>>>
>>>>>> 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.
>>>>>
>>>>> +1 for dropping "NullArgumentException" and letting the JVM raise NPE.
>>>
>>> I'll also create a JIRA issue for reaching a conclusion on this one.
>>
>> OK, I think we agree here. Phil preferred the way we created runtime
>> exceptions as of 2.1, though. Perhaps we could revive a simple
>> createNullPointerException without arguments ?
> 
> But why would one prefer to write
> ---
>   throw MathRuntimeException.createNullPointerException();
> ---
> instead of
> ---
>   throw new NullPointerException();
> ---
> ?

For example to have a single point where to put breakpoints for
debugging. I used that a lot as such exceptions mainly occur during
development phase.

> 
> Not only is this inconvenient, it is also dangerous: I was bitten more than
> once writing this:
> ---
>   MathRuntimeException.createNullPointerException();
> ---
> which the compiler happily accepted.

Of course, as it would have accepted:

  new NullPointerException();

Unfortunately, we cannot put the throw inside the method. Trying to do
this prevent the optimizer to wor properly as it does not know in the
caller that the method would never return, and it brings lots of
warnings from code checking tools for the same reason.

Luc

> 
>>>
>>>>>> Hoping to conclude this fast ...
>>>>>
>>>>> Let's not be too hasty ;-). There can be some work left for 4.0.
>>>>
>>>> I hope this would be algorithm work.
>>>
>>> New algorithms can always be included in 3.x releases. I was referring to
>>> a "refactoring" (which entails incompatibilities). This is not a bad thing;
>>> quite the contrary, this is how a programming project stays alive, in sync
>>> with technology advances, and keeps attracting developers.
>>
>> Yes, but lengthy and harsh discussions keep them away.
> 
> Indeed, indeed...
> 
> 
> Best regards,
> Gilles
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message