Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Sun, 6 Mar 2011 19:38:59 +0000 (UTC)
From: "Luc Maisonobe (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <499500921.37.1299440339628.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1983933205.82.1299420925135.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] Commented: (MATH-542) Allow the addition of multiple
 messages to the exceptions generated by CM
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Luc Maisonobe commented on MATH-542:
------------------------------------

No, users can't use [lang] ExceptionContext on [math] exception if [math] does not provide the same feature.
The key-value pairs are more general than Localizable-arguments and they may be used for something different than building a message.

I don't intend to suppress the Localizable-arguments part, just to add the possibility to add key-values. We could even use this to hold the Localizable and the arguments array if we want. So an exception would have at least the localizable and the arguments (enforced by constructor) but also additional parameters. Some of these parameters would be directly injected by [math] for some specific exceptions (iteration count, out of bound value ...) but the user could add its own, thus effectively removing some of the use of wrapping. The additional parameters are not intended to appear in the message, so there would not be a patchwork of languages in the final display.

The typical use case I have (from my own code) is something like a spacecraft maneuver planning algorithm that do call an optimizer from [math]. If the optimizer fails, we get some [math] exception. We just catch it, add some information about the context of the maneuver planning and throw the same exception again for the top level to catch it and react on the context information and decide if it can make another try (for example switch to another propulsion mode) or if it should give up and display the original exception (most of the time without its context, because when we decide to give up we want to display something more general than the context of the last attempt only).

> Allow the addition of multiple messages to the exceptions generated by CM
> -------------------------------------------------------------------------
>
>                 Key: MATH-542
>                 URL: https://issues.apache.org/jira/browse/MATH-542
>             Project: Commons Math
>          Issue Type: New Feature
>            Reporter: Gilles
>            Assignee: Gilles
>            Priority: Minor
>              Labels: api-change
>             Fix For: 3.0
>
>
> Borrowing on the idea of "ExceptionContext" implemented in [Lang], "MathRuntimeException" (base class of all exceptions generated from CM) will be enhanced so that an unlimited number of (localized) messages can be added to an exception object.
> The "MathThrowable" interface (implemented by "MathRuntimeException") will contain the following new method:
> {code}
> /**
>   * Sets a message.
>   *
>   * @param pattern Message pattern.
>   * @param arguments Values for replacing the placeholders in the message
>   * pattern.
>   */
>   public void addMessage(Localizable pattern,
>                          Object ... arguments);
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira