Question

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

以下是一个例子：

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

我很想使用CurrentCulture，如上所示，因为异常消息是针对人类的（当然，代码永远不会对异常消息本身起作用）。消息将使用客户端的文化格式化，因此每当我需要将其显示给我的客户端时，它看起来很不错。

但是，除了向用户显示消息外，还可以将异常记录到日志文件中。我看到很多邮件都放在我的日志文件中，各种文化用于格式化它们。蛮丑的！在这种情况下，InvariantCulture更合适，或者可能是托管日志文件的服务器的文化。

这里的要点是，在格式化异常时，您永远不会知道您的受众，因此在格式化时似乎无法确定要使用的文化。能够将格式推迟到捕获异常的位置会很棒，但这会超出.NET中实现异常的方式。

那你对此有何看法？

Answer 1

由于你的异常信息是英文的，我会坚持不变的文化。为什么要将英文文本与非英文数字格式混合使用？

但是，如果您尽可能本地化异常消息（如.NET框架那样），您可能希望使用所选资源程序集的文化。即使没有可用的本地化（即它可以回溯到英语），这也可以确保数字格式和语言匹配。

但是在我的理解中，异常消息主要是针对开发人员的。因此，我不会考虑将它们本地化，除非它是一个来自世界各地的开发人员的大项目。如果您无法处理异常，则应该捕获它并向用户提供一些在给定上下文中适当的错误消息（可能与异常消息一样精确或可能不准确）。

向他们提供异常消息本身（尤其是对于Web服务器）可以公开有关可能被恶意使用的服务器软件的详细信息。我认为最好记录异常并为用户提供（本地化）错误消息和一些数据，这些数据可以将日志事件（很可能是非本地化的，不变的文化）与他们的反馈相关联。

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

Answer 2

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

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

2 个答案: