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