修改

我问的是.NET本身是否能够为我提供一个我可以呈现的描述性字符串（并且与其他.NET程序一致）。我知道我可以卷起自己的，但如果有标准替代，我想避免这样做。

Answer 1

您可以拥有一组可本地化的用户例外，其中一个例外是FileUploadError。您可以在那里放置本地化的一般信息。抛出一些技术细节可能会有点挑战，因为在技术细节和用户修复错误需要采取的简单步骤之间取得适当的平衡可能非常困难。

我的建议是：

拥有一个用户级FileUploadErrorException
有详细信息属性
根据实际例外情况，建议用户尝试一些事情

Answer 2

如果您正在捕获其中一个.Net框架的File类引发的异常，那么异常的.Message属性的内容很可能已经被本地化。 .Message属性应包含本地化的人类可读文本。我认为它的“友好”取决于它，但它可能包含一些你可以嵌入更通用和友好段落的内容。

假设您可能会编写一些方法AlertUserWithMessage()来向用户显示错误，这可能会有用：

try
{
    fileStream.Read(...);  // or some other operation
}
catch(Exception e)
{
    AlertUserWithMessage(e.Message);
}

如果您想要包含可能对诊断问题的支持人员有帮助的其他信息，那么您也可以将堆栈跟踪作为异常的字符串。

try
{
    fileStream.Read(...);  // or some other operation
}
catch(Exception e)
{
    AlertUserWithMessageAndStackTrace(e.Message, e.StackTrace);
}

Answer 3

异常消息本质上是技术性的并且描述了出错的地方（在实现级别），而不是如何解决最终用户的问题。另一方面，呈现给用户的错误消息的目的是解释失败的原因以及采取什么措施来解决问题。例外消息和最终用户错误消息不具有相同的目的，也不是针对相同的受众编写的。

因此，对于体面的用户体验，将这些例外映射到关于如何解决问题的本地化用户友好建议要好得多。当然，对于技术用户来说，拥有一些可以提供异常细节的诊断功能可能会很不错（在这种情况下，使用英语的异常消息并不重要 - 英语实际上是世界上的技术语言），或者只是指向他们到了一个包含所有细节的日志。但是，在最终用户处抛出异常消息（甚至本地化）可能会让他们感到困惑。

因此我不认为本地化异常消息有多大用处。确实，.NET框架已经为主要语言提供了本地化的异常消息，但我认为更多是因为有些开发人员使用这些语言作为他们的基本语言并且不一定能很好地掌握英语。因此，这些本地化异常消息的受众仍然是开发人员，而不是使用.NET构建的软件产品的最终用户。

如何向用户报告标准例外？

修改

3 个答案: