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}", "entity.storage.failed", 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.)
Alex.
