ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button
Article:
  Best Practices for Exception Handling
Subject:   I18N and Exceptions?
Date:   2003-11-20 03:55:15
From:   bazzargh
Something that I'd like to see written about is internationalisation of exceptions. Obviously you can "throw new BlahException(MessageFormat.format(bundle.getString("myMessage"), args))". Unfortunately, in client/server systems, this formats error messages in the server's locale; that's pretty much unavoidable because third party libs will format their exceptions using the system-wide default locale - you can't set it on a single client's request thread, for example.


Obviously this isn't too much of a problem in (eg) websites where all the clients use one locale - you just switch the server locale too - the difficulty is running a truly multilingual site.


The upshot is that the exception messages are only useful in the server logs and shouldn't be passed on to the client, since they are likely to be in the wrong language. So best practice is that not only should end users never see stacktraces, the text of exception messages should never be shown to them (in a multilingual environment).


This can become incredibly awkward. For example, an XML schema validation error based on user input will almost certainly happen in a third party lib, and you can find yourself with nothing but the (wrong language) string to identify what went wrong.


So, anyone got advice, references for best practice for internationalized exceptions?


1 to 1 of 1
1 to 1 of 1