avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Nash <miken...@jglobalonline.com>
Subject Re: Do you *really* not need localized exceptions?
Date Thu, 25 Apr 2002 14:58:40 GMT

I've used the pattern you describe below (e.g. having two constructors for cascading exceptions
(except I called 'em ChainedException at the time), one with the usual String, and one with
a "Key"), and it worked very well - it also allowed me to internationalize as time and resources
permitted, starting with the places more likely to come up.

As long as "Key" and the internationalization code is "fail-safe", it doesn't add potential
subsequent exceptions to the mix - what I did was just have them return the key itself if
all else failed (e.g. if they couldn't get the message bundle or something else nasty went
wrong). In practice it seldom did.

Just my 2c worth...

JGlobal Ltd.

On Wed, 24 Apr 2002 20:18:59 +0200
"Stephen McConnell" <mcconnell@osm.net> wrote:

> Hi Ole:
> > -----Original Message-----
> > From: Ole Bulbuk [mailto:Ole.Bulbuk@ebp.de]
> > Sent: Wednesday, 24 April, 2002 17:55
> > To: 'Avalon Developers List'
> > Subject: AW: Do you *really* not need localized exceptions?
> >
> >
> > Stephen,
> >
> > thank you for you support and Berin, thank you for the translation. :-))
> >
> > > An observation: it is
> > > perhaps better
> > > to do the establishment of internationalization of the
> > > message directly
> > > in the classes CascadingException and CascadingRuntimeException. This
> > > fact I agree in general with your proposal.
> >
> > Putting internationalization directly into CascadingException would force
> > internationalization on everybody and could break the interface (a
> > constructor taking a String wouldn't make sense).
> Defining a specific constructor for an internationalised message would
> not break existing interfaces. In fact, I don't see why this couldn't be
> done
> such that it is totally transparent relative to existing implementation.
> I agree that string constructor doesn't make any sense beside this would
> conflict with the current implementation, however, a constructor that
> takes an i18n related typed argument could be introduced without conflict
> and would enable very simple migration on current non-i18n exception code.
> Consider the following (current) approach:
>   throw new CascadingException( "Sorry, it didn't work out", e );
> as opposed to:
>   throw new CascadingException( new Key("org.apache.myKey"), e );
> which would imply one new constructor on the exception while offering
> the scope for a variety of constructors on the typed argument (Key
> being just an example of a typed argument).
> > That is why I suggested an
> > additional base exception that extends CascadingException.
> In principal the *only* change would be an additional constructor,
> and some minor handler code inside the exception implementation to get
> the i18n message (preferable at the time the message is
> resolved).  Neither of these points impact the interface.  Secondly,
> the changes do not imply any behavioural change when invoking with
> the String/Throwable constructor pattern.
> > RuntimeExceptions are to be read only by developers. So they
> > could write the message in any language they like. Of course they
> > should take into account other developers too. But they needn't
> > consider administrators or users. So I don't know a reason to make
> > an internationalized version of CascadingRuntimeException.
> I have lots of cases where I'm catching and handling runtime
> exceptions.  I can provide much more context by wrapping the
> runtime causal exception with a application level exception and
> this results in meaningful error logging (and in some cases
> propagation of the exceptions between servers).
> > If something as bad as an Error occurs IMHO nobody will bother
> > about i18n (since this could produce further exceptions and
> > errors). So making an internationalized version of
> > CascadingError could be a waste of time too.
> I agree that it is not "normal" for applications to be throwing
> an Error.  However, lets assume there exist situations in which it
> may be appropriate .. i.e. "signalling an abnormal condition that
> should never occur". Including i18n support would be equally rational
> because this information can be logged just like any other throwable.
> Concerning time/effort, my hunch is that given a model for managing
> a typed i18n argument value, the actual code inside respective exceptions
> would be minimal (i.e. I'm guessing that the bulk of the i18n
> exception related handling could be done within the typed argument
> class).
> Cheers, Steve.

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message