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 Thu, 03 Mar 2011 16:04:32 GMT
Le 03/03/2011 16:34, Gilles Sadowski a écrit :
> Hi Luc,
> 
> Thanks for repeating that you agree with most points, as was the case with
> all the changes I had been implementing in "trunk".
> The discussion went awry when, because of a single point of disagreement
> (about whether a user-only "FunctionEvaluationException" should be defined
> in CM), all the work on the exception revamping of these past 6 months has
> been threatened of nullification based on matters of taste.
> 
> Below, I've heavily cut the quoted parts of the thread because it has become
> fairly difficult to distinguish the new information.
> 
>>>> 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.
>>>
>>> Out of curiosity, where can I read that "Request For Proposal"?
>>
>> Sorry, you cannot read it. It's access is restricted to the company who
>> were previously selected in a frame contract. It's for a public agency,
>> were we met a few months ago (but not for the same people).
> 
> I was asking because you said: "[...] public Request For Proposal [...]".
> 
>>>
>>>>  3) don't put all exceptions in a dedicated exception package
>>>>     (but the general exceptions used everywhere could go there)
>>>
>>> -0 because most exceptions are general and thus I don't see the benefit of
>>>    scattering the remaining few among several packages.
>>>
>>>>  4) put specific exceptions in the package they are triggered
>>>>     (for example ODE, linear ...)
>>>
>>> -1 unless we can be convinced that the specific exception has no usage in
>>>    another package (now and in the foreseeable future).
>>
>> 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.

> 
> 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.

> 
>>>
>>>>  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 ?

> 
>>>> 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.

Luc

> 
> 
> Best,
> 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