geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "gianny DAMOUR" <>
Subject Re: [i18n] Hardcoded message strings
Date Mon, 25 Aug 2003 23:25:49 GMT

>> defines the following messages:
>>00001=Authentication failed ${0} ${1}.
>>00002=Authentication failed#2.
>Can you say why '00001' is better than 'authFailed'?

I do not say that 00001 is superior than authFailed. One can use whatever is 

>I don't see the advantage of:
>public JavaMailMessage FAILED = new JavaMailMessage(00001); // NB this is 
>an 'octal' number, and (00010) has the value 8, so be careful :-)
>public String FAILED = "mail.authFailed";

In the first case, I can ensure that the message identifiers provided to the 
I18NJavaMailException constructor is a defined, because it is an element of 
a specific type-safe enum. In the latter case, it is possible to provide an 
undefined key to this constructor.

>I don't think i18n needs to create a bunch of exceptions specific to i18n. 
>Otherwise, for every Exception, you'll have an I18NXxxException, which 
>sounds like a lot of work. Sometimes I think it would be useful, but not 
>all the time.

As said by dain - dain, correct me if I am wrong - it allows to define 
distinct exception streams. Each stream can have its own last resort 
exception handling mechanism.

For instance, based on the class of an exception, one derives the affected 
sub-system and how to handle it. If the exception is a 
I18NJavaMailInternalException, then the last resort mechanism traps it and 
processes it. If it is a I18NJavaMailExternalException, then the last resort 
mechanism traps it, processes it and re-throws it to the client.

BTW, as said by others, and based on the KISS principle, a standard i18n 
approach is fine for the time being.


Hotmail : un compte GRATUIT qui vous suit partout et tout le temps !

View raw message