[
https://issues.apache.org/jira/browse/MATH-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984154#action_12984154
]
Phil Steitz commented on MATH-487:
----------------------------------
Another way to think about this is what abstraction makes sense at the API
boundary where the exception is being propagated. In this case, it is obvious
to me that "convergence exception" is much better than "some number became
infinite." A well-designed exception hierarchy enables the right abstraction
to be expressed in the different exception use cases, which to me means that
the exception conveys information to the caller that makes sense in the context
of the public API (i.e., without having to look at the code or know the details
of the implementation). When a continued fraction (or quadrature method, or
rootfinder, or....) fails to converge, conveying that directly in the exception
is appropriate, IMO. We can certainly talk about how this abstraction may fit
into a more fully articulated hierarchy, but I am -1 on just dropping it at
this point.
While we all agree that we need a better-designed hierarchy, we are struggling
with how that hierarchy should be structured and how it should be connected to
the concepts in the Commons Math API. I think it is best at this point to
close this issue, but reopen the discussion on the mailing list on how best to
structure our exceptions hierarchy. I think we first need to agree on some
principles. If what I have stated above about connection to the context of the
public API, for example, is not acceptable, we need to reach consensus on an
alternative that we can all support. I apologize for "more complaining than
coding" in this area up to now. I will fix that.
> Deprecate "ConvergenceException" in MATH_2_X and remove it in trunk
> -------------------------------------------------------------------
>
> Key: MATH-487
> URL: https://issues.apache.org/jira/browse/MATH-487
> Project: Commons Math
> Issue Type: Improvement
> Reporter: Gilles
> Assignee: Gilles
> Priority: Minor
> Fix For: 2.2, 3.0
>
>
> The checked "ConvergenceException" should be deprecated.
> An example usage is in class {{ContinuedFraction}} (package {{util}}), at
> line 153:
> {noformat}
> if (scale <= 0) { // Can't scale
> throw new
> ConvergenceException(LocalizedFormats.CONTINUED_FRACTION_INFINITY_DIVERGENCE,
> x);
> }
> {noformat}
> I think that it should be replaced by a more specific (and unchecked)
> exception that reflects the exact low-level problem:
> {noformat}
> if (scale <= 0) { // Can't scale
> throw new NotStrictlypositiveException(scale);
> }
> {noformat}
> A few lines below that, there is:
> {noformat}
> if (infinite) {
> // Scaling failed
> throw new
> ConvergenceException(LocalizedFormats.CONTINUED_FRACTION_INFINITY_DIVERGENCE,
> x);
> }
> {noformat}
> So it seems that it is not necessary to throw an exception at the place where
> the test on "scale" fails; instead we could have:
> {noformat}
> infinite = true;
> if (scale <= 0) { // Can't scale
> break;
> }
> {noformat}
> and let the check on "infinite" throw the exception:
> {noformat}
> if (infinite) {
> // Scaling failed
> throw new
> NotFiniteNumberException(LocalizedFormats.CONTINUED_FRACTION_DIVERGENCE,
> Double.POSITIVE_INFINITY, x);
> }
> {noformat}
> As shown in the above excerpt, we could also replace two {{enum}}:
> * CONTINUED_FRACTION_INFINITY_DIVERGENCE
> * CONTINUED_FRACTION_NAN_DIVERGENCE
> with a single one:
> * CONTINUED_FRACTION_DIVERGENCE
> because the other bit of information (infinity vs NaN) is already given by
> the first parameter of the message.
> What do you think of these changes?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
