commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <>
Subject Re: [all] exceptions and localization
Date Sun, 04 Feb 2007 19:43:51 GMT
On 2/4/07, Luc Maisonobe <> wrote:
> Phil Steitz wrote :
> >
> > The problem with that is that generic handlers that display messages
> would
> > not work. I like the idea of carrying the data along, though and
> exposing
> > it, as well as providing translate (see
> >
> >
> >
> > )
> > and getMessage(Locale) methods.  That gives client apps the most
> > flexibility.  What do you think, Luc?
> Trying to synthetize all use cases, here is what I think is expected by
> everyone who has expressed views :
> 1) allow application level code to contribute to/configure  message
> building
> 2) allow low layers to build messages with variable parts
> 3) allow localized messages
> 4) expose message parts (key and parameters)
> 5) allow handlers using only no arguments getMessage() to work as usual
> 6) use a mechanism robust enough to work even in case of code changes
>      and missing localization data (of course in degraded, i.e. non
> localized
>     mode)
> The following proposal is an attempt to address all these points.
> 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.
> Does this seems sensible ?

I don't think we are going to please everyone here, Luc, and I agree with
Stephen that we don't want to over-complicate or get into the
framework-building business, but I disagree with the statement that we
should make localization impossible in generating strings (even exception
messages).  My recommendation is that we just modify the Mantissa class to
expose the key and parts (so add members for them) and add
getMessage(Locale). That is simple, not far from what we already have, and
sufficient to meet localization needs and support other sorts of processing
for clients who want to do that.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message