15

It is probably related to "Who should read Exception.Message if at all" and similar questions asked on this site, but I don't see how it is possible to always generate a custom message while avoiding exception messages.

Also in .NET all exception messages are localized by default. Does it make sense or is it just a bad design? Moreover it is mentioned in guidelines on how to handle exceptions:

Include a localized description string in every exception. When the user sees an error message, it is derived from the description string of the exception that was thrown, rather than from the exception class.

In most cases it is pretty easy to catch and show an exception message to user instead of trying to analyze the exception type and then generating a proper user message depending on the exception details. Especially when the result turns out to be not really different from the original exception message. Also it may be a tedious work to analyze all possible cases, take a hypothetical example: you need to connect to some server over HTTP and read some XML message. There are tons of things that could go wrong, starting from port/host being unreachable, or not having access rights or malformed XML etc. Going over each case is a lot of work, while simply displaying the exception message is easy and it is very likely that it contains a user-friendly string.

So should I localize exception messages and display them to the end user as is, especially when generating a custom message may take some more unnecessary work? Or should I still do this work?

2
  • The up-to-date version of the .NET "Best Practices" (...cries in a corner...) article is available here: docs.microsoft.com/en-us/dotnet/standard/exceptions/…. And this is what they write: "The error message that the user sees is derived from the Exception.Message property of the exception that was thrown".
    – GOTO 0
    Jul 2, 2019 at 9:02
  • Our software runs on a Chinese computer and just throwed this one: 索引超出范围。必须为非负值并小于集合大小。参数名. Can you tell me what has gone wrong in our software? That's why exceptions should not be translated. Unfortunately, .NET automatically does this. Jul 7, 2022 at 7:19

3 Answers 3

19

I believe that logs and exceptions are for developers, therefore they should be in the best language to suit the development team. This may be their native language, however it may be (and judging from the comments often is) English. This allows developers to work in a language they are familiar with and not have to translate from French, Spanish, or Chinese to work a problem.

However, your users may not all be English speakers.

To give the best user experience you may well want to localise any error messages you feel you need to display to the user.

You could do that in a number of ways:

public class LocalisedException : Exception
{
   public string LocalErrorMessage {get; protected set;}
   public LocalisedException(string localErrorMessage, string englishMessage)
     :base(englishMessage)
   {
      this.LocalErrorMessage = localErrorMessage
   }       
}

Or (and probably the way I'd do it):

try
{
  DoSomethingExceptional();
}
catch(Exception ex)
{
  _log.Error("There was an error", ex);
  this.DisplayErrorMessage(LanguageResourceFile.ThereWasAnError);
}

My suspicion is that the author of the article you linked assumes you're going to be displaying ex.ErrorMessage directly to end users. I wouldn't do this, ex.ErrorMessage often contains technical (and sometimes even sensitive) details and should therefore not be shown. It also makes you THINK about what you are presenting to the user. Catching, logging, and apologising gets you into that habit.

In summary. I'd make sure your exceptions and logs are as easy and accessible for your developers as possible. But make sure that your website (and error messages displayed) as as clear for your users as possible.

8
  • 13
    I strongly disagree that exceptions should be in the same language as developers. Developers understand English and I personally hate when. NET framework throws a danish message making it much harder to google. Jun 21, 2018 at 16:56
  • 8
    @EsbenSkovPedersen Agree, I hate it when I get exception messages in my native language. Programming is done in English, stop being ashamed of this you native English-speaking framework developers.
    – Alex
    Jun 21, 2018 at 20:20
  • 5
    Thanks for the feedback guys, as an English speaker it's interesting that foreigners would rather have exceptions in English rather than their own language. I'm going to adjust my answer to reflect this
    – Liath
    Jun 22, 2018 at 8:17
  • 1
    @TimSchmelter they have to understand english in order to code in .NET, java, python, ruby or any other language I've heard about. Jun 27, 2018 at 10:52
  • 1
    All the apis are in English so if you can write code you are already using the English words. Also Exceptions are not able to transfer much info anyway. They are more like a key you can Google. Jun 27, 2018 at 12:45
8

By my opinion the exception message should not be translated.

  • if developer can reproduce the exceptional situation at their development environment, the message is not needed at all, they could just attach a debugger and set it up to break at throwing the exception. Exception messages mostly make sense for non-reproducible failures which happen only at production environment

  • in most cases, showing them to end user does not make sense. They are too technical for that. They should rather be logged, and users should get application specific description of what has failed.

  • for international environment, the localized messages from third party libraries are much harder to investigate. Even when I have the message text, automated translation provides only approximate information. Moreover, some people like to send a screenshot instead of text, which is close to useless for some Japanese or Arabic text.

0

No, you should localise Error Messages. Your users should never see an Exception Message. That is for your logs only.

Exceptions should never happen if you app is working. If you want to open a file for example, check that it exists and then open it. Don't try opening and throw an exception if it fails.

Of course that doesn't mean you can't tell the user the file doesn't exist! It just means they get a localised and user friendly Error Message, not an Exception Message

This way any exceptions can be treated as a crash, and a simple "Something bad happened!" message can be presented to the user, while your operations team gets the exception message with the detail on what went wrong.

*Of course if you are creating custom Exception classes in a multinational library, they will need localised messages for consumption by the developers of products that use the library.

8
  • 6
    if file exists, it does not guarantee subsequent open call would succeed
    – max630
    Jun 21, 2018 at 17:46
  • "for example" did you really want a full break down of possible race conditions?
    – Ewan
    Jun 21, 2018 at 17:49
  • 2
    I just want to say that failures are always possible, and pre-checking does not solve it.
    – max630
    Jun 21, 2018 at 17:55
  • 1
    "check that it exists and then open it" does not mention any lock
    – max630
    Jun 21, 2018 at 18:15
  • 1
    I disagree. Exceptions are fine for things like input validation as they bring you up the stack trace to where the processing of the request terminates and a sensible error message can be produced. I agree that there's no point in translating the exceptions as the end user should never see them anyway. However, I disagree with your last point about multinational library - English messages are much better for googling and this advantage is so huge, that nearly all developers profit from having original messages, even those speaking very bad English.
    – maaartinus
    Jun 27, 2018 at 10:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.