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

当抛出异常时，我经常传入格式化的字符串，公开有关发生问题的详细信息。如果可能的话，我总是指定一个格式化提供者（这是很好的做法，否则你可能会忘记决定哪种文化是合适的，因为缺省是当前的文化，这可能导致很多错误）。使用InvariantCulture或CurrentCulture格式化异常消息？

下面是一个例子：

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

我很想用CurrentCulture，如上图所示，由于异常消息针对人类（ofcourse，代码不应该对异常消息本身行事）。消息将使用客户端的文化进行格式化，因此无论何时我需要将其展示给我的客户端，它看起来都不错。

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

这里的要点是，格式化一个异常时，你只是永远不知道你的受众，所以当格式化时决定使用哪种文化似乎是不可能的。如果能够将格式推迟到捕获异常的地方，那将是非常好的，但这将超出在.NET中实现异常的方式。

那么你对此有何看法？

来源

2010-07-07 Sandor Drieënhuizen

既然你的例外信息是英文的，我会坚持不变的文化。为什么要混合英文文本和非英文数字格式？

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

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

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

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

来源

2010-07-07 13:44:20 ollb

谢谢，这些都是很好的论点。我曾经想过在每当发现一个未处理的异常时（例如在global.asax中的ASP.NET中）向用户显示异常消息，但我同意最好记录异常并显示通用（本地化）消息。该方法使整个故事变得简单：使用InvariantCulture始终格式化异常消息，并且不会将消息公开给客户端。 – 2010-07-07 14:44:06

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

来源

2011-05-03 11:56:55 MagicBuzz

这是一个有趣的想法。 – 2011-05-03 12:03:46

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

回答

相关问题