geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@coredevelopers.net>
Subject Re: [i18n] Hardcoded message strings
Date Tue, 26 Aug 2003 16:30:50 GMT
On Tuesday, August 26, 2003, at 02:42 AM, Alex Blewitt wrote:

> On Tuesday, Aug 26, 2003, at 00:25 Europe/London, gianny DAMOUR wrote:
>
>>> 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()

This is a bad idea.  Either the message carried by the exception is an 
indecipherable key or the key is a full message.   The former makes 
debugging hard, and the latter makes keeping the message bundles up to 
date basically impossible.


If we are going with i18 Exceptions (and I have yet to see a real call 
from users), I think we should make all Exceptions support an 
*optional* message key.  When we construct a exception we do something 
like this:

throw new GeronimoEJBException(
         "Storage of Entity failed: entityType={0}, entityPk={1}",
         "entity.storage.failed",
         new Object{entityType, pk},
         sqlException);

A few things to note:

* This is what I think is the easiest version of what has been 
suggested in the emails
* The message is defiantly targeted at developers
* The code is written in english
* The real information of this exception is enclosed in the 
sqlException which is most likely not i18.

I think the last point is the most important.  I know of no other 
opensource projects that do this for exception messages, so even if we 
did add it, developers are no better off considering we are in the 
middle and most of the real problems will happen in the lower layers. 
Does Java even support i18 exceptions from the platform classes?

When it comes to info, warn, error and fatal log messages, I think the 
is an argument for i18.  As opposed to i18 exceptions, this is common 
and there is support built into Log4j and JDK logging.

-dain

/*************************
  * Dain Sundstrom
  * Partner
  * Core Developers Network
  *************************/


Mime
View raw message