geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Blewitt <>
Subject Re: [i18n] Hardcoded message strings
Date Tue, 26 Aug 2003 07:42:55 GMT
On Tuesday, Aug 26, 2003, at 00:25 Europe/London, gianny DAMOUR wrote:

>> 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 
>> :-)
>> over
>> 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.

Good point, well made. Of course, you still have the same problem in 
the new JavaMailMessage("mail.authFailed") that the key may not exist, 
so this moves the location of where the error may occur, unless you 
check the string in the constructor of JavaMailMessage to make sure it 
exists beforehand.

>> 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.

But wouldn't this last resort exception handling mechanism be the same 
for any exceptions?

Also, should we have an I18NException, or should we just pass the 
message key as the 'message' for any generated exceptions? When it 
comes to printing/logging them out, we can use

String message = bundle.get(exception.getMessage());
if (message == null)
   message = exception.getLocalizedMessage()

That way, if an exception contains a key as a message, it will use 
that; otherwise (if it is not found) then it will use the message in 
its entirety for the result. Plus, it should therefore be easy to spot 
where messages don't have translations, because they'll just end up 
with the key name.

> 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.

Many of the spec-based APIs can't have extra exception types added to 
them, so this would only work if both were subclasses of  
RuntimeException (which is often seen as not a good practice). However, 
what works better is to throw a new MessagingException with an embedded 
(say) I18NException, or failing that, just the message key (and 
getLocalizedMessage() can be overriden to provide the lookup behaviour).

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

Always good to discuss the possibilities and come up with a standard 
that can be put up on the Wiki site so that others can follow, too. 
Better that we all use the same mechanism than having a separate 
mechanism per module :-)


View raw message