Home/ Questions/Q 905325
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-15T16:11:57+00:00

When throwing exceptions, I often pass in a formatted string that exposes details about

  • 0

When throwing exceptions, I often pass in a formatted string that exposes details about the problem that has occurred. I always specify a formatting provider if possible (which is good practice because otherwise you may forget to decide which culture is appropriate and as the default is the current culture, that can lead to many bugs).

Here’s an example:

throw new InvalidOperationException(
    string.Format(
        CultureInfo.CurrentCulture,
        "{0} is a bad number.",
        number));

I’m tempted to use CurrentCulture, as shown above, because exception messages are targeted at human beings (ofcourse, code should never act on the exception message itself). The message will be formatted using the client’s culture so whenever I need to display it to my client, it looks nice.

However, besides displaying messages to users, exceptions may be logged to a log file as well. I’ve seen many messages sit in my log files, with all kinds of cultures used for formatting them. Pretty ugly! In this case, InvariantCulture would be more appropriate or perhaps the culture of the server that is hosting the log file.

The point here is that when formatting an exception, you just never know your audience so it seems impossible to decide which culture to use when formatting. It would be great to be able to postpone the formatting to the point at which the exception is caught but that would go way beyond the way exceptions are implemented in .NET.

So what are your thoughts on this?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Since your exception message is in English, I would stick to the invariant culture. Why should you mix English text with non-English number formats?

    If you however go as far as to localize the exception messages (like the .NET framework does), you would want to use the culture of the selected resource assembly. This makes sure that number formats and language will match, even if there is no localization available (i.e. it falls back to English).

    However in my understanding exception messages are primarily meant for developers. Therefore I wouldn’t consider localizing them, unless it is a big project with developers from all over the world. If you can’t handle an exception, you should catch it and provide the user some error message that is appropriate in the given context (and which might or might not be as precise as the exception message).

    Providing them with the exception message itself could (especially for web servers) expose details about the server software, which could be used maliciously. I think it is better to log the exception and provide the user with a (localized) error message and some data that makes it possible to associate the log event (most likely non-localized, invariant culture) with their feedback.

    WCF for example will not report back exception details to a user, unless being explicitly configured this way. See IncludeExceptionDetailInFaults configuration setting and the “caution” block there.

    • 0