You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Gilles (JIRA)" <ji...@apache.org> on 2010/04/01 12:16:27 UTC
[jira] Created: (MATH-361) Localization and Error Handling
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
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.
[jira] Commented: (MATH-361) Localization and Error Handling
Posted by "Luc Maisonobe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12882301#action_12882301 ]
Luc Maisonobe commented on MATH-361:
------------------------------------
We all agree we need to reduce the number of enums.
What I don't agree with is the fact error messages are for the set of users that must read the javadoc. Error messages are for end users, some of them not even knowing commons-math is used in an application they use. They don't read the javadoc, they don't develop the application.
But when a statistician tries to set up a gamma distribution and get a message about alpha being negative, he will better understand what his input error was than if a generic "negative parameter" message was displayed.
Perhaps this example about alpha is a little extreme, and I won't argue long for this specific exception if you insist on it being replaced by a more general one. But don't be too drastic in the reduction of the number of messages and more importantly don't consider messages are for developers using directly commons math. There will be lot of layers between our very low level component and a complete end user application, but some messages will go through all these layers and be finally displayed to users. These messages should provide as much information to them as we can provide.
Users are the most important part of a system.
> 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.
[jira] Commented: (MATH-361) Localization and Error Handling
Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12883008#action_12883008 ]
Phil Steitz commented on MATH-361:
----------------------------------
Hopefully we can have it both ways here - improve the exception hierarchy and maintain informative failure-capture information in exception messages. I don't think it makes sense to argue about who the exception messages are for - developers at all levels in the application hierarchy, end users (in some cases) or production support people may all have occasion to look at stack traces or exception error messages. We are all thankful to API developers who provide good exception error messages. Currently, commons math provides pretty good failure-capture information in exception messages and I would like to make sure that we do not lose that. We can add more state and structure to the exception hierarchy, but I would like to see us maintain informative exception error messages including meaningful failure context information.
I understand and support the desire to reduce the number of distinct error messages that we maintain in the enums, but I really think we need to balance user (that means whoever is looking at stack traces or logs including our exception messages) convenience with making things simpler for us. If I were chasing down a bug in my upper level code that was trying to create a gamma distribution with a negative shape parameter, I would find my problem quickly if I saw an IllegalArgumentException thrown by setAlphaInternal with a message telling me that alpha was negative. However we refactor things, I want it to stay that easy - no needless forays into the javadoc (which may not always be readily available) or having to insert instrumentation to recover failure-capture information.
> 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.
[jira] Commented: (MATH-361) Localization and Error Handling
Posted by "Gilles (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12877801#action_12877801 ]
Gilles commented on MATH-361:
-----------------------------
Revision 953668 contains a stripped-down of CM with a working version of the source files modified according to the proposal.
The code is in the ["sandbox" area|http://svn.apache.org/viewvc/commons/sandbox/commons-math_l10n/trunk/] of the repository.
Since the part of the proposal concerning the possibility of having a run-time selection of the localization library did not elicit a strong interest, the version shown there is the "simplest" case, where the dependency on the (external) library "cal10n" is _not_ optional.
Please have a look.
Notes:
# I had to modify some files due to dependencies on files which I had removed.
# I had to comment out some statements (e.g. in test files that referenced "TestUtils" which I had removed).
# I modified the "pom.xml" file:
** to include the new dependency on the "cal10n" library
** so that the resources (localized messages text) are included in the JAR (but this has the side-effect of including the "templates" directory, contrary to what was done by default)
> 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.
[jira] Commented: (MATH-361) Localization and Error Handling
Posted by "Luc Maisonobe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12879575#action_12879575 ]
Luc Maisonobe commented on MATH-361:
------------------------------------
First step of correction has been committed to subversion repository as of r955423.
I have reduced the number of messages by grouping very similar ones, but there is still a lot to do on this field.
Gilles, you can now go ahead with the remaining part. I may have to polish a little my part but think we can work in parallel without major problems now.
> 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.
[jira] Commented: (MATH-361) Localization and Error Handling
Posted by "Gilles (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12886890#action_12886890 ]
Gilles commented on MATH-361:
-----------------------------
As I understand it, this utility could be a library independent from CM (although obviously it should stay in sync with it). That's the sort of thing I hinted at when I was talking, a few comments back, of a high-level interface to CM.
I think it's a good idea especially for the kind of use-cases which Phil and Luc were mentioning. But they won't agree to depend on an external library for this service. And I still think that cramming even more of this kind of information (non-essential to the working of the core functionality) inside CM is not the right way to go.
> 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.
[jira] Commented: (MATH-361) Localization and Error Handling
Posted by "Ole Ersoy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12883355#action_12883355 ]
Ole Ersoy commented on MATH-361:
--------------------------------
What about having a Enum class with a minimum set of constraint messages used throughout the core library and another set of Enum classes that have messages specific to Mathematical Context of each CM class?
So for example the GammaDistribution would only use the minimum set of Enum messages. If an application developer wanted the CM library's help in giving end users more specific error messages, she could use the GammaDistributionMessageEnum class, which contains messages more specific to the scenarios that arise if users use the GammaDistribution class in ways that violate its constraints.
Perhaps a simple utility to go along with this that she could use to get the "The shape parameter of the Gamma Distribution cannot be negative" message, to display in the user interface, when the user tries a negative value.
> 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.
[jira] Updated: (MATH-361) Localization and Error Handling
Posted by "Gilles (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gilles updated MATH-361:
------------------------
Attachment: l10n.tar.gz
The attached file contains a demo implementation of the proposal.
When unpacked, there will be 3 base directories (each one is meant to generate a separate JAR file):
- l10n_fw-cm/
Files to be added/modified in the CM distribution.
- l10n_fw-nodep/
Files that implement the "no-dependence" localization framework.
- l10n_fw-cal10n/
Files that implement a bridge to the "CAL10N" localization library.
> 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
>
>
> 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.
[jira] Commented: (MATH-361) Localization and Error Handling
Posted by "Luc Maisonobe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12878713#action_12878713 ]
Luc Maisonobe commented on MATH-361:
------------------------------------
The localization process is the part on which I did not agree with your proposal, but trying to set up some more meaningful exception can be done with both solutions: it is a completely separate problem.
# There is no tool I know of that does the checks I would like to add.
# Throwing localization away (read with an external framework) when it consists in one interface and one enumerated class is adding lots of complexity for a basic feature (CM is a math library, localization is important I think but it is not the core of the library and should not be over-engineered)
# Dependencies are a good thing for high level application or libraries and are a very bad thing for low level components, CM is a low level component
# I don't agree we need a pluggable localization framework, we need simple localization
# Fine if there is no bug, but cal10n does implement its own logic for finding resources and its own parser for properties file (another kind of reinventing the wheel ...)
I don't think reinventing the wheel is not a real problem: it's so simple, it can be redone twice a day. Reinventing the car including all its embedded electronics would be a problem. The difference is on complexity and as such is a trade off. You talked earlier on the KISS principle, this is a good advice and I think one interface and one and an half implementation is simpler that adding both a framework and a pluggability layer.
> 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.
[jira] Commented: (MATH-361) Localization and Error Handling
Posted by "Gilles (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12886563#action_12886563 ]
Gilles commented on MATH-361:
-----------------------------
Revision 962306 implements some practical middle ground. It is based on my not-so-"clumsy" suggestion (cf. the end of the lengthy discussion on the "dev" ML) to create a detailed message from 2 enums.
If the most specific exception classes (i.e. at the bottom of the hierarchy) are not specific enough, they should provide a second constructor where the first argument is a {{Localizable}} pattern that further specifies in which context this error occurred. This is similar to what is passed to the current calls to {{MathRuntimeException.createIllegalArgumentException(...)}}.
In this way:
# There will be zero loss of information at the level of leaked messages.
# It will not be necessary to create a bloated set exception classes.
# The actual problem is reported by a stateful exception.
> 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.
[jira] Commented: (MATH-361) Localization and Error Handling
Posted by "Gilles (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12882589#action_12882589 ]
Gilles commented on MATH-361:
-----------------------------
{quote}
What I don't agree with is the fact error messages are for the set of users that must read the javadoc. Error messages are for end users, some of them not even knowing commons-math is used in an application they use. They don't read the javadoc, they don't develop the application.
But when a statistician tries to set up a gamma distribution and get a message about alpha being negative, he will better understand what his input error was than if a generic "negative parameter" message was displayed.
{quote}
At best, there is lot of confusion (about exception usage) in these statements. I guess that part of it stems from the fact that you are CM-developer, CM-user, CM-service provider, CM-based application developer, CM-based application user, ...
First, the error messages are indeed for the user of CM, that is the _programmer_ that uses the low-level CM library to build a high-level application. If he lets the CM exception propagates upwards to _his_ users, that is sloppy design.
To be more precise, in the "statistician" example, what do you mean by "tries to set up a gamma distribution"? The answer is:
* either he is coding something himself (thus he _is_ the application programmer, and must read the Javadoc, etc.)
* or he is using a software that will call CM methods. The programmer of that software must have read the Javadoc (where it is indicated that "alpha" must be positive) and if he called "setAlpha" with a negative argument anyways, that is a _bug_ in his program.
The Java language designers provided several mechanisms for exception handling but not always clearly promoted tried and true best practices. Fortunately some people did. Do you have access to a copy of Joshua Bloch's _"Effective Java"_? I found that the section on "Exception" is enlightening; especially, "items" 40, 41, 43, 45 address all we have been arguing about.
The bottom line is:
{quote}
[...] don't consider messages are for developers using directly commons math.
{quote}
The vast majority (of those triggered by precondition violations) should be for them.
{quote}
[...] but some messages will go through all these layers and be finally displayed to users.
{quote}
They shouldn't.
{quote}
These messages should provide as much information to them as we can provide.
{quote}
No, the "detail" message is a hint to get at the code and correct the bug.
{quote}
Users are the most important part of a system.
{quote}
Most important for CM are the users who use CM _directly_. Apart from doing correct computations (obviously), the library should be as easy as possible to use, while providing a robust and clear design that can stand as an example of best programming practices and enhance development. That may come at odds with short-term demands of some top-level (indirect) users. [Like those who require to see error messages in French!]
The huge amount of error messages may be welcome in a high-level application, a sort of "mat(hematical) lab(oratory)" powered by CM, but not in CM itself.
> 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.
[jira] Commented: (MATH-361) Localization and Error Handling
Posted by "Luc Maisonobe (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (MATH-361) Localization and Error Handling
Posted by "Ole Ersoy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12886916#action_12886916 ]
Ole Ersoy commented on MATH-361:
--------------------------------
I agree with the thinking there. Also since each CM core library class (Say GammaDistribution) does not directly depend on GammaDistributionMessageEnum, these enums can easily exist in their own jar, separately from the core CM library (But should still be a part of CM). The package namespace should stay the same also. So for example if I look in the message enum jar under the namespace
org.apache.commons.math.distribution I see:
* BetaDistributionMessageEnum
* BinomialDistributionMessageEnum
* CauchyDistributionMessageEnum
* Etc.
Also in order to make the javadoc for the core CM library less verbose, the use case description javadoc could go in the MessageEnum classes. This way the core CM library stays very minimal and easy to maintain. Having the per class enums also then provides a more natural home to place developer friendly comments on how to go about providing the best end user experience for a given core CM class. This could also have a dual purpose as a best practice checklist to the developer, reminding them of things they should do when developing with a core library class.
Another thing is that if it's done like this, CM does not really have to care how the messages are resolved. CM could provide a utility if it wants to (might as well since it needs to resolve the core minimal enum messages), but the application developer does not have to use this utility. The application developer could resolve the enum messages using CAL10N if she wants to.
> 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.
[jira] Commented: (MATH-361) Localization and Error Handling
Posted by "Ole Ersoy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12886808#action_12886808 ]
Ole Ersoy commented on MATH-361:
--------------------------------
The one enum per class idea is meant to enable detailed context messages for end users. I'm suggesting that this enum only be used to communicate messages for end users. I, and I think you as well, think that the core CM library classes should not use this enum at all. The core CM library should only use the minimal set of Enums that are very generic. Then if the maintainer of a specific class wants to provide additional messages that capture the context of a problem to a greater extent, they should go in a separate Enum class that matches the class that would have generated the exception with the generic enum.
Note that with this approach, an exception does not necessarily have to be generated in order for an application developer to make use of the Enum messages accompanying a class.
For instance there may be a "Alpha parameter field" where the user enters a number. If the number is negative, the application pulls a Commons Math provided message that says that the "Alpha parameter of the Gamma Distribution must always positive".
So the goal of having an Enum per class, is to have all messages that could be helpful to an end user ready to go. The javadoc could then go into further detail with respect what would trigger the need to show these messages to the end user.
So for instance the javadoc could say that "if a negative alpha parameter is submitted it will trigger a PositiveNumbersOnlyException (With the generic "Only positive numbers allowed" message ). If you are an application developer, avoid this exception being triggered by first validating that the number is negative, and if it is, show the following message from the GammaDistributionEnum class to your user....
> 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.
[jira] Commented: (MATH-361) Localization and Error Handling
Posted by "Gilles (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12883139#action_12883139 ]
Gilles commented on MATH-361:
-----------------------------
{quote}
I don't think it makes sense to argue about who the exception messages are for [...]
{quote}
I think the opposite, because it has an impact on the library design.
Not that CM cannot go on with the current way; but my point is that Luc and you are focusing on top-level users while stressing that CM in a low-level component. To me, that is a blatant contradiction that produces drawbacks which I presented in several usage examples (which you didn't address), while you always reply with a single use case where the user is yourself (i.e. a CM developer). Anyone else who is using a high-level application based on CM will be baffled by the "detailed exception message" because, in all but the most trivial case, his actions will have only a remote connection to the exception triggered by CM.
I'm pinpointing at a minute detail of the design of CM, explaining that it can come in the way of some direct users of CM. The current long list of errors is in fact imposing your view (of what is important) to future application developers. [As an example, let's say that someone wants to create a GUI (e.g. for the statistician referred to above), he will want to define his own detailed error messages to be displayed in the GUI with a formatting of his choice. The statistician will never see the messages created by CM.]
If a CM exception (resulting from a precondition violation) reaches the end-user level, it means there was some unanticipated problem in the call chain. And to correct it, one would need more than just the "detailed message": the end-user will pass the stack trace to the application developer, who will correct a possible bug in his code (such as a missing check of a precondition) or pass it on the the CM developers.
> 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.
[jira] Issue Comment Edited: (MATH-361) Localization and Error
Handling
Posted by "Gilles (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12882142#action_12882142 ]
Gilles edited comment on MATH-361 at 6/24/10 10:22 AM:
-------------------------------------------------------
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 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?
was (Author: erans):
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.
[jira] Commented: (MATH-361) Localization and Error Handling
Posted by "Gilles (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (MATH-361) Localization and Error Handling
Posted by "Gilles (JIRA)" <ji...@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.
[jira] Commented: (MATH-361) Localization and Error Handling
Posted by "Gilles (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12886557#action_12886557 ]
Gilles commented on MATH-361:
-----------------------------
I think that this "one enum per class" idea will make the number of similar enums/messages explode: even if the problem is exactly the same in two different classes, two enums (and two messages) will have to be defined.
> 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.
[jira] Commented: (MATH-361) Localization and Error Handling
Posted by "Gilles (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12878938#action_12878938 ]
Gilles commented on MATH-361:
-----------------------------
{quote}
There is no tool I know of that does the checks I would like to add.
{quote}
"cal10n" comes with JUnit tests (and a Maven plugin, which I couldn't make work, probably because of my lack of knowledge...) that check the consistency of the localization files.
{quote}
Throwing localization away (read with an external framework) when it consists in one interface and one enumerated class is adding lots of complexity for a basic feature (CM is a math library, localization is important I think but it is not the core of the library and should not be over-engineered)
{quote}
Localization is not important for CM. [It might be for some users; it may also be a nuisance for others (cf. one of the examples I gave before: some scientist uses a non-English locale for a text processing application, but still expects the CM error messages to be in English). Selecting a "framework" at runtime allows the user to plug in a "no-op" library that won't do any localization. Admittedly, the CM code will be slightly more complex but all in all, it is just some 3 or 4 classes with less than a dozen lines!]
And, as you say in the next point: CM is a low-level component; but, IMO, localization is a high-level feature.
In my view, implementing CM's own localization code _is_ over-engineering, because the alternative of grabbing an off-the-shelf component like "cal10n" is _zero_ work.
Also, localization is, obviously, the core of "cal10n" so that the designer may already have thoroughly thought about the problem and come up with the most appropriate solution...
Finally, it is not because something is easy to do, that you should do it: laziness is one of the virtues of programming ;-) in that it leads to modularization and code re-use.
{quote}
Dependencies are a good thing for high level application or libraries and are a very bad thing for low level components [...]
{quote}
Why?
{quote}
I don't agree we need a pluggable localization framework, we need simple localization
{quote}
I warned before that it could be dangerous to assume what users will need, or not, in the future...
{quote}
[...] cal10n does implement its own logic for finding resources and its own parser for properties file [...]
{quote}
You caught me here... Although maybe not: what if he did this with good reason (efficiency)? The guy is the author of Log4J and its successors. Theses tools came when something similar already existed but (from what I've read) the new design solved a few annoying things in the previous solutions.
All that being said, I again stress that localization is not my main point here; then let's go back to "error handling" which, indeed, I want to be _separate_ from the "localization" issue:
{quote}
trying to set up some more meaningful exception [...] is a completely separate problem.
{quote}
To restate my previous question (about replacing literal strings with an {{enum}}), what will be the programming interface for CM developers? Something like this
{code}
throw new MathRuntime.createIllegalArgumentException(LocalizedMessages.OUT_OF_RANGE, x, xMin, xMax);
{code}
or something like that
{code}
throw new OutOfRangeException(x, xMin, XMax);
{code}
Do we agree on the second form? I.e.
* a stateful exception class (with accessors to the instance variables)
* inheriting (in this case) from {{IllegalArgumentException}}
* where all references to localization are completely encapsulated
Is so, then the rest of the discussion (on the best way to provide the localization feature) is not high priority (and can be postponed), and I absolutely don't mind that you implement your proposal in the meantime.
To summarize, my request would become that we implement a set of exception classes (in a new "exception" package) from which we can pick appropriately and use as easily as in the second example above.
> 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.
[jira] Commented: (MATH-361) Localization and Error Handling
Posted by "Gilles (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12879299#action_12879299 ]
Gilles commented on MATH-361:
-----------------------------
{quote}
[Of course these are incompatible changes and would be postponed until work on release 3.0 is started.]
{quote}
I meant that only the incompatible changes should be postponed until 3.0, but that the deprecation should be performed now and the new exceptions added as soon as possible.
> 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.
[jira] Updated: (MATH-361) Localization and Error Handling
Posted by "Gilles (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gilles updated MATH-361:
------------------------
Attachment: res.tar.gz
Example translation files.
> 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.
[jira] Commented: (MATH-361) Localization and Error Handling
Posted by "Luc Maisonobe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12878427#action_12878427 ]
Luc Maisonobe commented on MATH-361:
------------------------------------
I finally found some time to look at this issue and the proposal.
I agree with the problems and not with the solution. I don't like adding a dependency only for the sake of development ease and NOT for users. End users will not see any improvement with this and they will have to manage yet another dependency which is not widespread and on which we have no control. Adding also a complex management to allow working without the dependency also misses the point I tried to make in the previous discussions: it removes the dependency but removes the localization entirely!
I tried another approach on last three days. My proposal is simply to address the main problems with our current awkward implementation but without adding any dependencies. It is simply a matter of adding one interface with one main implementation (and another tiny dummy implementation for some compatibility purposes and to add new exception constructors.
The interface is called Localizable and declares two methods getSourceString() and getLocalizedString(Locale). A new enum called LocalizedMessages implements the interface and all its constants (249 so far) provide one message format, and mainly replaces the current MessageFormat class. The localization are loaded from a properties file. In the commons-math code, we will use only the enum constants, so there will not be any literal string spread throughout the library. In the enum class, there will be the default english format, this is a very important point as it allows to provide a formatted and understandable default message even if a locale is not supported or if the properties file for the locale is incomplete. I don't think cal10n does this. The properties file for a locale does not contain the english message, it uses the name of the constant as the key, so their is absolutely no duplication of any string literal.
The exceptions can be built using an enum where they used to have a pattern string. since the enum implements Localizable, the exception message can be built both using getSourceString without localization or usgin getLocalizedString(Locale) in any Locale (not only the default one). The existing constructors are preserved (but deprecated). This is very important for compatibility purposes because some of our exceptions are really intended to be extended by users since this is the way they can generate errors in the callback objects they implement themselves and provide to the library (ODE problems, functions to solve, ...). Many users WILL have extended these exception and used the only constructors we provided with String parameters. In this case, a dummy implementation of the interface is also provided to still get meaningful messages. As an added benefit, users will be able to also localize their own messages if they want, they simply have to provide their own implementation of the interface (hence we can separate several sets of constants, as the commons-math enums will not clash with the users enums).
It is quite easy to switch progressively from the current implementation to the one I propose. I also think we could have some very simple tools to check our properties files are complete and we have no unused enum constants. Since we use standard properties files and not a dedicated parser (which is what cal10n uses, with some parsing bugs on single quotes I think), it will later be possible to go to some more adequate tooling on the localization process (at development time) by using for example the xliff oasis standard that allow translators to use their own tools (including Machine Translation or Computer Aided Translation) and create java properties files (their are some free tools to transform xliff to standard java properties files).
As the changes in the commons-math code are really straightforward and can be automatized, I can handle the transition of ALL existing messages.
> 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.
[jira] Commented: (MATH-361) Localization and Error Handling
Posted by "Gilles (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12878452#action_12878452 ]
Gilles commented on MATH-361:
-----------------------------
>From what I can gather from the above description, I'm sure that what you propose is an improvement on the current implementation. But I also doubt that it addresses all the points I've made.
Especially, is it correct that each literal string key will be replaced with an equivalent instance of an {{enum}}? If so, it does not solve the issue of a user who would want to programmatically access specific information (that should be carried along within a specific, stateful, exception object), and not just read a message log.
Concerning the dependency:
# No dependency is nice, but reinventing the wheel is _not_ (such as re-writing a tool to check a re-written localization process...).
# IMHO, CM should not contain any "cosmetic" code, such as localization handling. It should only be concerned with throwing stateful exceptions. Couldn't we provide a separate library that, given an exception generated by CM, would turn it into a localized message?
# What is the problem with having dependencies? Is it good that people use CM but not that CM use the work of other people?
# My initial proposal contains the possibility of a _pluggable_ localization framework. This functionality can then be provided through an existing library or through a wheel invented here ;-). The interface mandates just one method: {{getMessage}}. [I didn't implement it in the "sandbox" because the dependency didn't seem to be such a problem for most people.]
# There is no bug in "cal10n" parsing of single quotes; the behaviour is actually mandated by {{java.text.MessageFormat}}.
> 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.
[jira] Commented: (MATH-361) Localization and Error Handling
Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12879205#action_12879205 ]
Phil Steitz commented on MATH-361:
----------------------------------
I agree with the following points from the discussion above.
1. We need to continue to support localization.
2. We should not introduce an external dependency if it doesn't make things significantly easier for us or our users.
3. Luc's proposal for cleaning up localization support is no more work and does not appear to be any harder to maintain than Gilles' proposal to use cal10n.
4. We should refactor our exception hierarchy over time, moving some of what is now in messages into exception state / typing.
5. Exception refactoring needs to be done with consideration for users of the existing exceptions.
So I would say go ahead with Luc's last suggestion - make the enums change and then separately address the exception hierarchy. It would probably be best to open separate tickets for the exception hierarchy changes.
> 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.