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