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