使用 InvariantCulture 或 CurrentCulture 格式化异常消息?

发布于 2024-09-08 04:35:18 字数 696 浏览 5 评论 0原文

引发异常时,我经常传入一个格式化字符串,该字符串公开有关已发生问题的详细信息。如果可能的话,我总是指定一个格式提供程序(这是一个很好的做法,因为否则您可能会忘记确定哪种区域性是合适的,并且由于默认是当前区域性,这可能会导致许多错误)。

这是一个例子:

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

我很想使用 CurrentCulture,如上所示,因为异常消息是针对人类的(当然,代码永远不应该对异常消息本身进行操作)。该消息将使用客户的文化进行格式化,因此每当我需要将其显示给客户时,它看起来都很不错。

然而,除了向用户显示消息之外,异常也可以记录到日志文件中。我已经看到许多消息位于我的日志文件中,并且使用各种文化来格式化它们。相当丑陋!在这种情况下,InvariantCulture 可能更合适,或者可能是托管日志文件的服务器的区域性。

这里的要点是,在格式化异常时,您永远不知道您的受众,因此似乎不可能决定格式化时使用哪种文化。如果能够将格式化推迟到捕获异常的时间点,那就太好了,但这将远远超出 .NET 中实现异常的方式。

那么您对此有何看法?

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?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

左秋 2024-09-15 04:35:19

由于您的异常消息是英文的,因此我会坚持不变的文化。为什么要将英文文本与非英文数字格式混合在一起?

然而,如果您要本地化异常消息(如 .NET 框架所做的那样),您可能希望使用所选资源程序集的区域性。这可以确保数字格式和语言匹配,即使没有可用的本地化(即回退为英语)。

然而,据我了解,异常消息主要是针对开发人员的。因此我不会考虑对它们进行本地化,除非这是一个由来自世界各地的开发人员组成的大项目。如果您无法处理异常,则应该捕获它并向用户提供一些适合给定上下文的错误消息(并且可能与异常消息一样精确,也可能不那么精确)。

向他们提供异常消息本身可能(特别是对于 Web 服务器)暴露有关服务器软件的详细信息,这些详细信息可能会被恶意使用。我认为最好记录异常并向用户提供(本地化)错误消息和一些数据,使日志事件(很可能是非本地化的、不变的文化)与他们的反馈相关联。

例如,WCF 不会向用户报告异常详细信息,除非以这种方式显式配置。请参阅 IncludeExceptionDetailInFaults 配置设置和“小心”挡在那里。

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.

空城旧梦 2024-09-15 04:35:19

恕我直言,您可以使用异常类的“Data”属性。
这样,您可以将要记录的不变消息存储在“Message”属性中。
您可以向“Data”集合添加一个密钥对值,其中 Key =“UIMessage”且 Value = 您的 ui 消息,其格式正确地适应用户文化(并且可能是根据正确的文化翻译的您的消息)。
在异常处理程序中,您可能只需在消息属性和数据对之间进行选择,即可记录或显示正确的消息。

IMHO you may use the "Data" property of the exception class.
This way, you may store in the "Message" property the invariant message you want to log.
And you could add to the "Data" collection a keypair value with Key = "UIMessage" and Value = your ui message properly formatted to the user culture (and may be your message translated according to the right culture).
In your exception handler, then you may just have to choose between the Message property and you Data pair in order to log or display the proper message.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文