Hi Ole:
> -----Original Message----- > From: Ole Bulbuk [mailto:[EMAIL PROTECTED]] > 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. > Regards, > > Ole > -- > Ole Bulbuk Tel.: 0331/74759/60 > Ernst Basler + Partner Fax: 0331/74759/90 > Tuchmacherstr. 47 E-Mail: mailto:[EMAIL PROTECTED] > 14482 Potsdam WWW: http://www.ebp.de > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
