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

San*_*zen 3 .net c# resources exception cultureinfo

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

这是一个例子:

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

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

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

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

那你对此有何看法?

oll*_*llb 5

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

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

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

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

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