Localization of Exception messages

[Guest]

I have an hard time figuring out how to deal with localization and Exception
messages.

I have some options:
1) Standardize on english.
2) Pass an "Error Number" to my exceptions, which would ultimately translate
to something localized if the app ever wants to display it (by calling the
Message property).
3) Use the System.Resources namespace classes each time I throw an exception
to make sure the right message is passed to the exception at creation.

If I want to localize the throwing of an ArgumentException exception, for
example, then only the first method (obviously) and the third method would
localize the error message. With the other method, I would have to subclass
ArgumentException to my own LocalizedArgumentException that takes an error
number (which map to a localized error message) in argument.

Anyway, I'm really stuck here, conceptually speaking. I don't know what are
the best practices regarding that matter.

Etienne Fortin


Of the three methods, only the third one, which I don't like (efficiency
reason), allows localization of standard .NET Framwork exceptions throwing.

 

[Anders Norås [MCAD]]

I have some options:

1) Standardize on english.

Exceptions shouldn't be shown to end users so I reckon this should be
sufficient. You should consider catching all exceptions and showing a
localized, user friendly error message if an unresolvable issue arises.

2) Pass an "Error Number" to my exceptions, which would ultimately
translate
to something localized if the app ever wants to display it (by calling the
Message property).

Since exceptions are strongly typed there is no need for error numbers.
Instead you can identify exception by their type.

3) Use the System.Resources namespace classes each time I throw an
exception
to make sure the right message is passed to the exception at creation.

If you need localized exceptions this is the way to go. With regard to your
concerns about efficiency I you shouldn't be noticing any degraded
performance unless you're throwing tons of exceptions. If this is the case,
you're probably not displaying your exceptions to the end user any way,
hence removing the need for localized exceptions.
You should note that throwing and catching exceptions is an expensive
operation performance wise, reading resources is not an expensive operation.

My recommendation is that you standardize your exceptions on a single
language and catch all exceptions and display localized error messages (not
exceptions) to the end user when there is a need for this.

Anders Norås
http://dotnetjunkies.com/weblog/anoras/

 

[Guest]

Hi Anders,
Thanks for your answer.

The problem I see is that it's perfectly legal to display the Message of an
Exception to the user as an error message. I understand that this will not
necessarily happen for each exception, but it may happen.

And exception messages may vary depending on the context and the situation.
A method can throw an ArgumentException with some message, and the other with
another. I can't localize stricly on the ArgumentException Type since the
message is not garanteed to be the same with each instance I catch.

Etienne

 

[David Levine]

I have an hard time figuring out how to deal with localization and
Exception
messages.

I have some options:
1) Standardize on english.
2) Pass an "Error Number" to my exceptions, which would ultimately
translate
to something localized if the app ever wants to display it (by calling the
Message property).
3) Use the System.Resources namespace classes each time I throw an
exception
to make sure the right message is passed to the exception at creation.

Using option 1 is the easiest but the least user friendly. You may need a
combination of option 2 and 3. The problem is compounded when dealing with
a client-server located on physically separate machines; exceptions on both
machines may need to be localized using different cultures. Or you may wind
up needing to pass the client's culture to the server so it can use that as
the culture to use for messages.

If I want to localize the throwing of an ArgumentException exception, for
example, then only the first method (obviously) and the third method would
localize the error message. With the other method, I would have to
subclass
ArgumentException to my own LocalizedArgumentException that takes an error
number (which map to a localized error message) in argument.

I wouldn't subclass each type. However, if you can map the technical,
low-level reasons into a smaller set of higher level exception types, more
along the lines of business logic exceptions, then you may be able to reduce
this to a smaller set of possibilities. You could then pass that custom
exception type to the client and localize at the point you render the
exception into a message.