>I am somewhat confused with Brad Abrahms' Exception Message Guidelines
>(http://blogs.msdn.com/brada/archive/2004/01/28/64255.aspx), also published
>now in the book. One of his suggestions is:
>
> "Do localize exception message".
These guidelines are targeted at API developers. The "user" mentioned in
the guidelines is actually a developer that is programming against an API,
not an end-user of an application. Requirements for localizing exception
messages within your own applications may differ quite a bit from these
general API guidelines.
> This works fine as long as the application runs in a desktop. It gets more
> complicated when we are in a client/server environment, and server does
[quoted text clipped - 3 lines]
> Still it needs to set Exception's Message property, and it is recommended
> to be localized.
In this scenario, the server-side exception message should probably never be
seen by the client user. There are several reasons for this, not least of
which is that the server-side error message might expose information about
potential security weaknesses that could be exploited by a malicious end
user. If you are going to log server-side exceptions, the exception
messages should be localized into a language that their eventual consumer
will understand. This would usually be the server or application
administrator, whose language choice could be very different from that of
the end user.
> So we in our development team came to conclusion that we can't use Message
> property to display a message to end-user. We will need to build separate
> resource tables that will contain local exception message texts. And
> Message can only be used internally for debugging purposes.
Good idea all around, assuming that your client-side exception messages do
not reveal potentially "sensitive" information about the application and its
supporting services and infrastructure.
> Has anyone come to a better appoach?
The only approach that might be even "better" would be allowing viewing-time
localization of a server-side exception log in case administrators have
different language preferences. Unfortunately, while you might be able to
do this for your own exceptions, you won't be able to do a proper job of
this for the exceptions thrown up from within the .NET Framework itself, so
it's probably not worth the bother unless the relevant members of your
application/server support team really do not share a common language.
Vagif Abilov - 26 Oct 2005 16:10 GMT
Thanks Nicole! I have now better confidence in our approach :-)
Vagif
>>I am somewhat confused with Brad Abrahms' Exception Message Guidelines
>>(http://blogs.msdn.com/brada/archive/2004/01/28/64255.aspx), also
[quoted text clipped - 45 lines]
> relevant members of your application/server support team really do not
> share a common language.