3

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

这是一个例子：

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

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

但是，除了向用户显示消息外，异常情况也可能会记录到日志文件中。我已经看到我的日志文件中有许多消息，其中包含用于格式化它们的各种文化。真是丑！在这种情况下，InvariantCulture可能更合适，或者可能是托管日志文件的服务器的文化。

这里的重点是，在格式化异常时，您永远不了解您的受众，因此似乎无法决定在格式化时使用哪种文化。能够将格式化推迟到捕获异常的时间点会很棒，但这将超出在 .NET 中实现异常的方式。

那么您对此有何看法？

4

2 回答 2

5

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

但是，如果您要对异常消息进行本地化（如 .NET 框架所做的那样），您可能希望使用所选资源程序集的区域性。这确保了数字格式和语言将匹配，即使没有可用的本地化（即回退到英语）。

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

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

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

于 2010-07-07T13:44:20.943 回答
1

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

于 2011-05-03T11:56:55.180 回答