Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Message-ID: <28379360.13411276628844587.JavaMail.jira@thor>
Date: Tue, 15 Jun 2010 15:07:24 -0400 (EDT)
From: "Luc Maisonobe (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Subject: [jira] Commented: (MATH-361) Localization and Error Handling
In-Reply-To: <588355934.629481270116987224.JavaMail.jira@brutus.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Luc Maisonobe commented on MATH-361:
------------------------------------

Dependencies are a good thing for high level applications because they help modularization (just as you said). Dependencies are a bad thing for low level components because lots of such components are included in middle and high level applications and so their is easily a tremendous amount of management work when you combine everything. I guess you have already heard about the "jar hell" when several intermediate libraries of a single application depend on different version of the same low level component. I simply don' t want to add just one other dependency especially since I'm still not convinced about the interest for end users.

I think the reason cal10n implemented it's own parser is to allow different characters encoding (properties files can be encoded only in ASCII or iso-latin1 up to Java5), but I'm not sure. I know who wrote cal10n and know he also wrote log4j and slf4j, and I respect his work. I only say cal10n and Apache commons-math does not seem to be a good fit to me: we are too low level. It is similar to the other thread about logging (but this issue is not the place to deal with this).

Concerning the two proposals for exceptions, I would say both can be used, it really depend on the exception. I agree we have a too limited set of exception and hence reuse liberally too general exceptions. I don't think all of our exceptions should have dedicated classes, this would be a nightmare to document and most users would still probably catch only the top level class of the hierarchy (i.e. MathException or MathRuntimeException). There is certainly a trade-off between the two extremes. Creating progressively new exceptions (like OutOfRangeException) is certainly a good thing.

So I would propose I first implement the localization change by only changing the literal strings to the enums (and adding the new constructors and deprecate the old ones) and after that you add you new exceptions.


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