commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [all] exceptions and localization
Date Tue, 30 Jan 2007 13:32:11 GMT
Craig McClanahan wrote:

> I'm late to the table on this thread, and only care about the Commons
> libraries I care about :-)

Thanks for your interest in this thread.

> but you should be aware that this attitude will
> disqualify the use of such libraries from use within code from organizations
> that have strict rules about implementing localization.  I work for such an
> organization (Sun) ... the key rules are that any message that might be
> visible to users *must* be localizable.

I agree with you and thought localization should be provided by the layer which
provides the message. Other people think this should be done at application
level, if done at all.

> For log messages, that tends to translate into a straightforward policy that
> DEBUG and TRACE type messages do not need to be localized, but anything from
> INFO level above must be.  The issue for exception messages is a bit more
> interesting.  How does the library developer know whether or not the message
> part of the exception will be displayed to end users?  From a pragmatic
> viewpoint, you can pretty much assume this will happen with exceptions in
> webapps, while many Swing apps will hide that sort of stuff to some degree.

I think that since low level components may be used almost anywhere, their
messages *may* be displayed and this sole possibility is enough to justify a
localized version should be made available. If the application gets an error it
really doesn't know about, it can simply display it.

> But, as a bottom line, if I'm interested in maximum adoption of a Commons
> library I work on, I will diligently ensure that exception messages are
> localizable :-).

When I first started this long thread, I thought the need for localized error
messages as provided by exceptions was acknowledged by everyone and asked for
the way to implement it, starting from a simple one which already works. I was
wrong. The disagreement started about the need itself and slipped to the level
at which implementation should be done.

I would really like to reach a compromise on this issue, something that could by
accepted by everybody. I don't want to get banned with a -1 on a commit, but at
least a few people would like localized error messages that can be simply
forwarded upward from lower layers to upper layer for display without
processing. Standard java already provides Throwable.getLocalizedMessage() since
JDK 1.1. I could set up for [math] only an exception hierarchy that only add a
few constructors and an implementation of this method without any change in the
Throwable.getMessage() behaviour. Does this sound reasonable ?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message