 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / New Users / December 2004Localization of Exception messages
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. > 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/ 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 "Anders Norås [MCAD]" wrote: > > I have some options: > > 1) Standardize on english. [quoted text clipped - 26 lines] > Anders Norås > http://dotnetjunkies.com/weblog/anoras/ >I have an hard time figuring out how to deal with localization and >Exception [quoted text clipped - 9 lines] > 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. > Anyway, I'm really stuck here, conceptually speaking. I don't know what > are [quoted text clipped - 5 lines] > reason), allows localization of standard .NET Framwork exceptions > throwing.
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.