commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <phil.ste...@gmail.com>
Subject Re: [all] exceptions and localization
Date Sat, 03 Feb 2007 20:47:40 GMT
On 2/3/07, James Carman <james@carmanconsulting.com> wrote:
>
> Well, I wouldn't even provide a getMessage(Locale).  I'd leave it up
> to the running application to resolve the message.  For instance, in
> Tapestry, it doesn't use resource bundles to localize messages, at
> least not directly in application code.  It uses a special Messages
> object.  So, I would provide getKey()/getParameters() methods only and
> leave it up to the containing application to localize the text.  That
> way, they can give some context to the error message instead of
> relying upon us to be general enough.


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
http://svn.apache.org/viewvc/jakarta/commons/proper/math/trunk/src/mantissa/src/org/spaceroots/mantissa/MantissaException.java?view=markup
)
and getMessage(Locale) methods.  That gives client apps the most
flexibility.  What do you think, Luc?

Phil

On 2/3/07, Niall Pemberton <niall.pemberton@gmail.com> wrote:
> > On 2/3/07, Phil Steitz <phil.steitz@gmail.com> wrote:
> > > On 1/30/07, luc.maisonobe@free.fr <luc.maisonobe@free.fr> wrote:
> > > >
> > > > 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 ?
> > >
> > >
> > > Sorry  I was  out of pocket this week and could not reiterate my
> personal +1
> > > for moving forward as you suggest, Luc.  I will add a few of more
> comments
> > > below.  If anyone still has serious reservations - especially those
> who now
> > > or in the future may contribute to [math] - pls speak up;  otherwise
> we can
> > > move on.  Thanks to all who provided comments.
> > >
> > > 1) My initial +1 was based on the fact that the error management that
> you
> > > need to support this approach is in fact there in Mantissa and if you
> > > *don't* support localization when text is being generated, you either
> need
> > > to get into nonsense like parsing and translating error messages,
> > > complicating your exceptions hierarchy, or losing/hiding information
> at
> > > higher levels.  If you do the work to localize when the string is
> generated,
> > > that gives a choice at higher levels, which to me is goodness
> (assuming you
> > > are prepared to do the work and the implementation is robust against
> missing
> > > bundles, etc.).
> > >
> > > 2) Commons math generates error messages now, and should generate
> better
> > > messages (as Mantissa does) in the future that using applications may
> want
> > > to display to end users or in application logs.  I would like for
> those
> > > messages to be localizable.  If one of our solvers does not converge
> because
> > > initial values do not bracket a root, for example,  I would like the
> > > developer of a localized client application that uses the solver to be
> able
> > > to display that message directly in a log or to the user.  Whether or
> not
> > > logging is good or bad is completely irrelevant to this discussion.
> > >
> > > 3) Apache is a do-ocracy and we have a proposal before us to
> significantly
> > > improve exception management and error reporting in [math] by
> extending and
> > > leveraging the framework in Mantissa.  Luc is volunteering to do this
> and
> > > the only other active contributor to [math] who has chimed in (yours
> truly)
> > > is also in favor.  The arguments against are either it is too much
> work to
> > > implement exception error message localization or it may not be
> robust.  Luc
> > > is stepping up to *do* the work (actually, leverage work already
> mostly done
> > > in Mantissa) and I don't see robustness or performance risk in what he
> has
> > > implemented.  Pls speak up if I am missing something in the latter
> case.
> > > Therefore, appreciating the feedback from others and reservations
> about
> > > applying across commons, for [math] we should let Luc JFDI  - i.e.,
> move
> > > forward with the proposal.
> >
> > +1 to those that do the work decide the direction.
> >
> > The only comment I would make is that there are two scenarios for
> > application localization in terms of the user - single or multiple.
> > Single being your application runs in one Locale only and multiple
> > where you have users with different Locale. If you want to cater for
> > the later then the exceptions should contain keys/replacement values
> > and message be resolved when the user's Locale is known - which I
> > think is James Carman's suggestion. Messages could be resolved outside
> > of Math or you could provide a getMessage(Locale) method in your
> > exceptions.
> >
> > Niall
> >
> > > Thanks again, all, for this interesting discussion and thanks, Luc,
> for
> > > helping make [math] more localization-friendly.
> > >
> > > Phil
> > >
> > > Luc
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>

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