I agree with Stephen that the commons libraries probably don't need this type of support. They aren't doing anything that's "businessy" enough (and they're not supposed to) to make it relevant to the user (the user doesn't care that I'm using StringUtils to eat the white space out of a String). My point was that if you *are* going to do it, at least make it easy to extend/adapt.
I don't necessarily agree that the exceptions aren't used to convey information to the user. As I've said, I use a BusinessLogicException class in my code sometimes. I do this so that I don't have to come up with many different exception types (UsernameAlreadyExistsException, InsufficientFundsException, etc.) that really add no logic, but just let me know something different is going on. I can use localized messages for that case. On 2/4/07, Stephen Colebourne <[EMAIL PROTECTED]> wrote:
I'm sorry, but I find this extremely complicated and unreasonable. It really, really, really isn't a direction I want commons to take. Firstly, the use of a static will annoy the IoC (Spring) crowd, so that aspect of the proposal seems flawed. Secondly, this proposes adding a whole ream of new interfaces, classes, resources, factories and strategies to achieve this. All of this additional code will need to be documented in detail, with explanations of how to customise each part. Thirdly, we can be sure that you haven't met all the weird requirements that the users of the library will come up with. They will start asking for changes which will add even more bloat. Fourthly, since none of this is standard, each commons library will probably do it slightly differently, making using all of them together nigh on impossible. Let me be clear, this is a (mostly) well-designed solution to the perceived set of requirements. Its just that the requirements are in my view completely inappropriate. Exceptions are a programming tool. They are used by developers. They are not intended for user interaction. Ever. Adding ANY kind of localization behaviour to [math] or any other commons component is completely OUT OF SCOPE!!! [math] is a library of mathematics routines. Under no circumstances should I need to know or learn or have to worry about this or that localized configuration. Localization is completely orthogonal to the concept of well-tested robust mathematical routines. Finally, what is being proposed here is the creation of a FRAMEWORK. I am so opposed to this because I believe it is the antithesis of what the best commons components are, which is LIBRARIES. A library is simple. It does what it says it does. Without complication or need to buy into its specific religion. A framework is religious. You have to agree to its terms, and its way of doing things. Or choose not to use it. Commons has done pretty well in resisting the complications and religions of frameworks - we are a repository of libraries. So, what is appropriate? It is good to have multiple different exception classes, even as many as one for each different possible error. It is also good for those classes to store the data that caused the error as instance variables accessed by get methods. (http://joda-time.sourceforge.net/xref/org/joda/time/IllegalFieldValueException.html) But they should only have one error message, and no way to localize it (ie. there should be no error code for looking up resources). That is the role of the application/framework that embeds the library - and it can use the exception classname and get methods to access the data if required. Why? because every application/framework that does want to localize wants to do it differently. And in all probability, 90%+ of applications/frameworks don't want to localize at all. Stephen Luc Maisonobe wrote: > Two main classes would be used: the MathException base class and a > MessageFactory base class. MathException would delegate to > MessageFactory the task to build the message from its String key and > Object[] parameters (point 2). Both the key, parameters and message > would be available with appropriate getters (point 4 and 5). A static > method in MathException would allow upper layers to prepend a customized > MessageFactory instance (point 1) in front of already registered > factories following a chain of responsibility. The initial chain would > contain three different MessageFactory instances : > - a LocalizedMessageFactory using the key to retrieve a pattern from > a ResourceBundle for the default Locale (Locale.geDefault()) and > MessageFormat to build the message (point 3) > - a NonLocalizedMessageFactory using the key directly as a pattern > for MessageFormat > - a RawMessageFormat simply concatenating everything with toString > > The chain of responsibility is intended to provide robustness (point 6): > the first message factory providing a non null message is used. If a > factory fails, the next one is used. The last factory cannot fail. > > A user who simply wants to get messages localized for a Locale which is > not the default one would therefore only need to do : > > MathException.prependMessageFactory(new > LocalizedMessageFactory(myLocale)); > > This would work even if its locale is not supported as its factory would > always fail but the following ones would be triggered as needed. > > I think an appropriate policy would be to always use US-english patterns > as keys as it would allow to get meaningful messages even if everything > else fails, and as it would help the translators tasks. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
