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:
- error messages should be meaningful to end users who do not
know the application design
- meaningful error messages should include references to run time
data, not only a fixed message. For example if a file access fails,
I want both the name of the file and the reason (file not found,
permission denied ...)
- the previous item implies that error messages should be set up in the
lowest layers where the information is available
- an error at low level can be worked around at an upper level, or
dismissed or displayed thanks to an application-dependent medium.
Hence the message fate should be handled in the highest layer
(aplication)
- errors semantics may change as they bubble up through the layers. A
critical error in a low level algorithm (say no solution to some
problem) may be considered only as an end condition in some
intermediate search loop or even be the result that was seeked (I
used that operationally for years in order to compute launch windows
for satellites)
- as errors semantics change along their path through the middle
layers, the error message may be reset to become more user-friendly
if needed. For example "no solution found in the [0.2 0.7] interval"
may become "attitude constraints not fulfilled for launch date
2007-01-28T21:39:45Z".
- exceptions are great for handling the four previous items (creation
in the low layers, decision in the high layers, interception in
the middle layers, wrapping within other exceptions if needed)
- developer-oriented information is not a substitute to user-oriented
error handling. If only one is set up, it should be the user-oriented
one
- developer-oriented information should not be pushed in front of users
- developer-oriented information may be put in log files for later
analysis
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 ?
Adding localized error messages is another place for the application to
go wrong, so you're going to have to test this fully. After all, if you
get it wrong, you could lose the real exception and just get a
meaningless failed to localize exception. And thats a terrible outcome.
You are right. In the current Mantissa codebase, I used the english
error message format as the key to find the translation and use it
directly if no translation is found for that key. If some resource file
gets outdated, the end user will end up with an untranslated message,
which is a somewhat fail-safe behaviour. It's not perfect, for sure, but
it is quite efficient.
For the record, I would -1 any code commit to add localized error
messages to a component I actively commit to.
So we really have to sort out this issue before I start any work about
it, regardless of the fact that you commit or not to [math]. Your
opposition is strong enough and shows there is a serious
misunderstanding between us that must be ironed out.
Luc
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
