Women in Technology

Hear us Roar



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?

Full Threads Oldest First

Showing messages 1 through 1 of 1.

  • I18N and Exceptions?
    2004-03-31 11:18:56  vsonnathi [View]

    Check this article by Vladmir Roubstov:
    http://www.fawcette.com/javapro/2002_12/online/exception_vroubtsov_12_16_02/default_pf.aspx

    You might want to extended the classes there to take a user specific locale when returning the error codes.