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-361) Localization and Error Handling
Date Wed, 16 Jun 2010 10:10:25 GMT

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

Gilles commented on MATH-361:
-----------------------------

Just to make things real clear:
* I utterly dislike the current way of using a factory to generate exception because:
** it creates a "tasteless" (as opposed to "stateful") exception,
** it is ugly (from the developer's point of view)
** it is of very limited use (from the user's point of view) since, e.g. as I had outlined
in the original proposal, it makes it impossible for a high-level application, using CM as
a component, to customize the problem report to the user,
** it looks like a poor man's logging.
* 249 exception messages is much too much. I'm fairly sure that we can figure out a significantly
smaller set of exceptions that will encompass the vast majority of them. Adding a constructor
such as:
{code}
public  OutOfRangeException(String info, double x, double xMin, double XMax) {
    // ...
}
{code}
would take care of specifying the name of the wrong argument (if there are several of them
and there could be a risk of confusion).
Currently, most of the time, the message just duplicates part of the Javadoc; that's why there
are so many of them. The exception message should not be a manual! E.g. in the case of violation
of preconditions, it is enough that the user is reminded to "RTFM" :-).

As a consequence, I'd like:
# to deprecate the exception factory.
# to create an "exception" package that will contain all exception handling code.
# to deprecate all exceptions not located in the "exception" package.
# to review the over-use of checked exception, following up on the [MATH-195|https://issues.apache.org/jira/browse/MATH-195]
issue. IMO, this review should be based on the simple rules explained in J. Bloch's book _"Effective
Java"_.

[Of course these are incompatible changes and would be postponed until work on release 3.0
is started.]


> Localization and Error Handling
> -------------------------------
>
>                 Key: MATH-361
>                 URL: https://issues.apache.org/jira/browse/MATH-361
>             Project: Commons Math
>          Issue Type: Improvement
>    Affects Versions: 2.1
>            Reporter: Gilles
>            Priority: Minor
>         Attachments: l10n.tar.gz, res.tar.gz
>
>
> This proposal aims at easing the handling of error during algorithms development, and
also enhancing the flexibility of the error reporting (provide meaningful exception classes
and run-time selection of the localization formatting).
> More details at [http://www.mail-archive.com/dev@commons.apache.org/msg14570.html]

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