commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles (JIRA)" <j...@apache.org>
Subject [jira] Commented: (MATH-195) Inconsistencies in the Exception hierarchy
Date Fri, 02 Jul 2010 11:17:51 GMT

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

Gilles commented on MATH-195:
-----------------------------

How can you agree both with Sun and with Bloch? As summarized in Goetz's paper, according
to Sun, checked exceptions should be the norm while, for Bloch, it's the opposite (i.e. you
can go for ckecked if ... and if ... and if ...).
Also you certainly cannot assimilate Eckel's view to "bad Java programing". But, in effect,
over-use of checked exceptions leads to cluttered code which is one aspect of bad programming
(Java or not).
Again, I think that there is a confusion of roles and responsibilities. CM _has_ to fully
document the behaviour of its algorithms so that application programmers can handle everything
_if they want to_. It's not because Java has checked exceptions that there are a good thing
in most cases. The problem is choosing the policy: what must be checked and what must be unchecked?
And more difficult: what could be checked but could also be unchecked?
I hope that we agree that the vast majority of exceptions in CM must be unchecked (obvious
precondition violations)!
Then (following Bloch), the cost of having even very few checked exceptions can become large
in terms of mandatory additional {{try}}/{{catch}} code. Hence the general rule would be to
go to unchecked in borderline cases (such as for the {{ConvergenceException}}).
The policy which I've stated above is quite simple:
# The caller's action is a direct cause of the failure.
# The caller cannot recover.

If any one of those two statements is true then the exception should be unchecked.
The "BrentSolver" example does not pass the first condition. [Bloch gives examples where checked
exceptions are perfectly appropriate but I think that no similar situation ever arises in
CM code.]
The fact that you like to lean on the compiler ability to check the handling of checked exceptions
is IMHO no match to the argument of a simple policy that leads to a consistent design which
will help you in writing robust code without the need of this compiler feature.

In my use case of solvers, there is no possible recovery: the tolerance and maximum iteration
are set so that hopefully a sufficiently accurate solution will be found within a reasonable
amount of time. If a {{ConvergenceException}} is raised then either
* there is no solution, or
* the tolerance and number of allowed iterations are not compatible.

But whatever the cause (intrinsic impossibility in the first case or wrong usage in the second),
this will lead to a processing failure; so why should I be bothered with {{try}}/{{catch}}
blocks?

Besides all this, it's quite clear that it's not easy to create a good exception framework
(otherwise we wouldn't be discussing this issue); and because checked exceptions are part
of the interface, it becomes a big problem for a "work in progress" (meaning: we are stuck
between the need to evolve the design and backward-compatibility requirements).

And the cherry on top of the cake:
* There are about 240 occurrences of {{FunctionEvaluationException}} {{throw}} clauses.
* There are only about 35 {{catch}} blocks that handle the {{FunctionEvaluationException}}.
[I.e. CM itself doesn't have much use of the checked exception functionality.]
* Out of those 35 cases, about 30 are doing this:
{code}
catch (FunctionEvaluationException e) {
    throw new IllegalArgumentException(e);
}
{code}

QED! ;-)


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


Mime
View raw message