Return-Path: 
 <issues-return-14098-apmail-commons-issues-archive=commons.apache.org@commons.apache.org>
Delivered-To: apmail-commons-issues-archive@minotaur.apache.org
Received: (qmail 6121 invoked from network); 24 Jun 2010 12:46:19 -0000
Received: from unknown (HELO mail.apache.org) (140.211.11.3)
  by 140.211.11.9 with SMTP; 24 Jun 2010 12:46:19 -0000
Received: (qmail 33537 invoked by uid 500); 24 Jun 2010 12:46:19 -0000
Delivered-To: apmail-commons-issues-archive@commons.apache.org
Received: (qmail 32002 invoked by uid 500); 24 Jun 2010 12:46:16 -0000
Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:issues-help@commons.apache.org>
List-Unsubscribe: <mailto:issues-unsubscribe@commons.apache.org>
List-Post: <mailto:issues@commons.apache.org>
List-Id: <issues.commons.apache.org>
Reply-To: issues@commons.apache.org
Delivered-To: mailing list issues@commons.apache.org
Received: (qmail 30945 invoked by uid 99); 24 Jun 2010 12:46:14 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 24 Jun 2010 12:46:14 +0000
X-ASF-Spam-Status: No, hits=-2000.0 required=10.0
	tests=ALL_TRUSTED
X-Spam-Check-By: apache.org
Received: from [140.211.11.22] (HELO thor.apache.org) (140.211.11.22)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 24 Jun 2010 12:46:11 +0000
Received: from thor (localhost [127.0.0.1])
	by thor.apache.org (8.13.8+Sun/8.13.8) with ESMTP id o5OCjoYv014584
	for <issues@commons.apache.org>; Thu, 24 Jun 2010 12:45:50 GMT
Message-ID: <15968892.38211277383550034.JavaMail.jira@thor>
Date: Thu, 24 Jun 2010 08:45:50 -0400 (EDT)
From: "Gilles (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
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394
X-Virus-Checked: Checked by ClamAV on apache.org


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

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

I've created an "exception" package in r957518.

Currently, it contains 4 classes:
* {{MessageFactory}}: localized message formatting
* {{MathIllegalArgumentException}}: base class for exceptions that must inherit from the standard {{IllegalArgumentException}} [Examples are the shown in the last two classes.]
* {{DimensionMismatchException}}
* {{OutOfRangeException}}

Starting from this, I'd continue to create new exception classes as needed. The first step would be to hunt down all the precondition violation checks and replace the "MathRuntimeException.createIllegalArgumentException" calls by an instantiation of the appropriate subclass of the new  {{MathIllegalArgumentException}} class. I stress that this should lead to a reduction of the number of elements in the {{LocalizedFormats}} {{enum}}. Indeed, take this code for example:

{code}
/**
 * Modify the shape parameter, alpha.
 * @param newAlpha the new shape parameter.
 * @throws IllegalArgumentException if <code>newAlpha</code> is not positive.
 */
private void setAlphaInternal(double newAlpha) {
    if (newAlpha <= 0.0) {
        throw MathRuntimeException.createIllegalArgumentException(
              LocalizedFormats.NOT_POSITIVE_ALPHA,
              newAlpha);
    }
    this.alpha = newAlpha;
}
{code}

What advantage does one get by having a specific "NOT_POSITIVE_ALPHA"? This is redundant with the Javadoc. The actual error is that the argument is not strictly positive. The exception thrown must reflect that, and _only_ that. The user _must_ read the Javadoc (as stated in the user guide) in order to figure out why this error has occurred. Agreeing on this issue will enable the replacement of many message patterns by their common "error" description.
If you don't accept this simplification there can be no end in the {{enum}} list, and it will become increasingly difficult to reuse existing elements as the new cases will almost always be different (even if only slightly so), thus requiring yet another element!

Another point is that the old  {{DimensionMismatchException}} is a checked exception. I think that it was an unfortunate choice and the required change is not backward-compatible. Still IMO the change should be performed before release 3.0. In the meantime, is there a way to warn users that this change will occur?


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