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 17:03:40 GMT

On Tuesday, Aug 26, 2003, at 17:30 Europe/London, Dain Sundstrom wrote:

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

I disagree. You can have a meaningful key, even if it isn't a full 
message. ejb.entityStorageFailed tells me exactly the same thing as the 
message would, but in a terser form.

> 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}",
>         "",
>         new Object{entityType, pk},
>         sqlException);

Why bother putting a 'default' message type along with a message key? 
There isn't any point, and makes it even more difficult to see that 
you've got the translation in place. At least if you have the I18N 
bundle loaded it can be obtained automatically.

Note that 'getMessage()' is supposed to return the message, whilst 
'getLocalisedMessage()' [the one printed by all stacktraces] uses a 
I18N lookup that you can code yourself. The default one just returns 
getMessage(), so it'd be something to override in the appropriate 
exception hierarchies.

> A few things to note:
> * This is what I think is the easiest version of what has been 
> suggested in the emails

Even easier would be to get rid of the message and just use the key. 
Granted, we probably need an array of data objects to go with it, (you 
should have new Object[] {entityType, pk} above) and a nested exception 
is always going to be useful. Plus, it can be passed to the superclass 
ot handle.

> * The message is defiantly targeted at developers

Ditto without the message hard-coded in the application; it can be 
looked up from a message table and translated much easier with that.

> * 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?

Yes, Java supports I18N messages in a variety of different languages 
and formats. Have you tried switching your locale to 'french' or 
'german' and seeing messages?

Large vendors (IBM) will spend money translating their exception 
messages into other forms. (One of the benefits of an error code 
displayed along with a message is that even if the error message is in 
an undecipherable language, a user can still gain meaning from the 
error and look it up in a code book.)


View raw message