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: [snip] > 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 http://wiki.apache.org/avalon/AvalonNoLogging (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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
