commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <>
Subject RE: [all] exceptions and localization
Date Mon, 29 Jan 2007 07:56:47 GMT
Hi Luc,

Luc Maisonobe wrote on Sunday, January 28, 2007 10:06 PM:

> Stephen Colebourne a écrit :
>> I disagree strongly with the whole concept of localized exception
>> messages. Localization for users yes, but developers no.
> [snip]
>  > IMO, a localized application actually means localization
> for users, and
>  > implies nothing for developers.
> I agree with both your rationale and your conclusion, but not
> with the
> implications. For me, error messages are users oriented, not
> developers oriented.
> Here are the few rules experience has teached me in the past 20 years:


> If I understand your remark correctly, you do make the same strong
> difference between users and developers, but you seem to consider
> exceptions are for the latters. What do you provide to the
> formers for
> error messages ? And to what purpose do you use logging ?

Although you have also some valid points in your summary, one point I learnt in the last 20
years of programming is, that you cannot build a common library with meaningful exception
messages (or log entries) that really makes sense for a user in the context of an application
that builds on it. For logging see also (IIRC
it was Leo Simon's article).

We have some global players as customers and they all have very specific needs for logging
and error messages (e.g. every logged entry has to be defined and must have an ID and has
fields with fixed length, exceptions have to be reported as part of the return value of service
calls again with special identifiers and filled-in parameter values for the error).

My bottom line: If you build an application, you have to do localization (of exception and
logging) at the application layer, because only there you can give the user a context, that
is really useful. This implies catching exceptions from libraries and wrapping them with your
own and it implies also, that you should have access to the basic parts of the exception (e.g.
the file name) easily i.e. usign the exeption's API. This part can be provided by a common
lib (and the JDK fails here often enough badly), but it cannot serve the requirements of an
application it has no knowledge of.

- Jörg

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message