commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Colebourne <>
Subject Re: [all] exceptions and localization
Date Sun, 04 Feb 2007 18:30:43 GMT
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.

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.


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:
For additional commands, e-mail:

View raw message