[jira] Issue Comment Edited: (MATH-195) Inconsistencies in the Exception hierarchy

["Gilles (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/MATH-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12884238#action_12884238 ] 

Gilles edited comment on MATH-195 at 7/1/10 7:34 AM:
-----------------------------------------------------

My opinion is that in CM all exceptions should be _unchecked_. Note that this does not imply that when such an exception is triggered, it will abort the program: like a checked exception, an unchecked one can be caught by the caller. Of course, to be able to do this, CM must fully document all the exceptions that can possibly be thrown.
I'm arguing for this position based on _"Effective Java"_ (cited in the article I referred to above):

{panel:title=Item 40|borderStyle=solid}
Use checked exceptions for recoverable conditions and runtime exceptions for programming errors.
{panel}
{panel:title=Item 41| borderStyle=solid}
Avoid unnecessary use of checked exceptions. In other words, don't use checked exceptions for conditions from which the caller could not possibly recover, [...]
{panel}

The example where the use of checked exceptions was advocated:
{quote}
The underlying principles for exception handling in Mantissa were that business domain exception (i.e. mathematics related like convergence or the likes) should be checked exception. These kind of errors may appear in perfectly valid code if given bad or insufficient data. Hence, these are expected errors and handling them appropriately in calling code is mandatory. In Mantissa spirit, unchecked exception were reserved for "impossible cases" [...]
{quote}
leads me to the opposite conclusion for the following reasons:
* What belongs to "business domain" could be left to be defined by the application. We should not force our view of what should be dealt with (by mandatory {{try}}/{{catch}} blocks).
* The situation where some code is given bad or insufficient data, can be deemed as a precondition violation even if in some cases it will not be obvious and cannot be simply checked at method entry. If some algorithm fails, it could be that
** either there is a bug in it or
** it was not appropriate to use it.
The CM policy could be that it throws an unchecked exceptions in both cases. [As already said, a user who is aware of an  algorithm's limitation (like sensitivity on input data) can catch the exception and do whatever pleases him (e.g. retry with better input).]
* The preceding point indeed shows that the call resulted in an "impossible case" (even if it could only be ascertained after some non-trivial computation), hence should trigger an unchecked exception.

If we agree that the use of checked exceptions should be restrained to situations where these conditions both hold:
# the caller's action is not the cause of the failure,
# the caller can do something to recover,

I don't see anything in CM that would require them.
I'd add (although I know that it shouldn't be the definite argument) that this "simplistic" policy will obviously ease development (both of CM and of applications using CM).


      was (Author: erans):
    My opinion is that in CM all exceptions should be _unchecked_. Note that this does not imply that when such an exception is triggered, it will abort the program: like a checked exception, an unchecked one can be caught by the caller. Of course, to be able to do this, CM must fully document all the exceptions that can possibly be thrown.
I'm arguing for this position based on _"Effective Java"_ (cited in the article I referred to above):

{panel:title=Item 40|borderStyle=solid}
Use checked exceptions for recoverable conditions and runtime exceptions for programming errors.
{panel}
{panel:title=Item 41| borderStyle=solid}
Avoid unnecessary use of checked exceptions. In other words, don't use checked exceptions for conditions from which the caller could not possibly recover, [...]
{panel}

The example where the use of checked exceptions was advocated:
{quote}
The underlying principles for exception handling in Mantissa were that business domain exception (i.e. mathematics related like convergence or the likes) should be checked exception. These kind of errors may appear in perfectly valid code if given bad or insufficient data. Hence, these are expected errors and handling them appropriately in calling code is mandatory. In Mantissa spirit, unchecked exception were reserved for "impossible cases" [...]
{quote}
leads me to the opposite conclusion for the following reasons:
* What belongs to "business domain" could be left to be defined by the application. We should not force our view of what should be dealt with (by mandatory {{try}}/{{catch}} blocks).
* The situation where some code is given bad or insufficient data, can be deemed as a precondition violation even if in some cases it will not be obvious and cannot be simply checked at method entry. If some algorithm fails, it could be that
** either there is a bug in it or
** it was not appropriate to use it.
The CM policy could be that it throws an unchecked exceptions in both cases. [As already said, a user who is aware of an  algorithm's limitation (like sensibility on input data) can catch the exception and do whatever pleases him (e.g. retry with better input).]
* The preceding point indeed shows that the call resulted in an "impossible case" (even if it could only be ascertained after some non-trivial computation), hence should trigger an unchecked exception.

If we agree that the use of checked exceptions should be restrained to situations where these conditions both hold:
# the caller's action is not the cause of the failure,
# the caller can do something to recover,

I don't see anything in CM that would require them.
I'd add (although I know that it shouldn't be the definite argument) that this "simplistic" policy will obviously ease development (both of CM and of applications using CM).

  
> Inconsistencies in the Exception hierarchy
> ------------------------------------------
>
>                 Key: MATH-195
>                 URL: https://issues.apache.org/jira/browse/MATH-195
>             Project: Commons Math
>          Issue Type: Improvement
>    Affects Versions: 1.1, 1.2, 2.0, Nightly Builds
>            Reporter: Thomas Chust
>            Assignee: Gilles
>            Priority: Minor
>             Fix For: 2.1
>
>   Original Estimate: 0.17h
>  Remaining Estimate: 0.17h
>
> I think there are some inconsistencies in the hierarchy of exceptions used by the Commons Math library which could easily be fixed:
>   - org.apache.commons.math.linear.MatrixIndexException should really be a subclass of
>     java.lang.IndexOutOfBoundsException.
>   - Either org.apache.commons.math.linear.InvalidMatrixException should be checked or
>     org.apache.commons.math.random.NotPositiveDefiniteMatrixException and
>     org.apache.commons.math.geometry.NotARotationMatrixException should be unchecked, but in any case the latter two
>     should be subclasses of the former. An unchecked InvalidMatrixException should probably be a subclass of
>     java.lang.ArithmeticException while a checked InvalidMatrixException should be a subclass of
>     org.apache.commons.math.MathException.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.