使用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格式化異常消息？

回答

相關問題