考虑一个 C# GUI 应用程序,它使用 aFileStream
来读取文件,由用户通过“打开文件”对话框选择。
如果读取失败并出现异常之一,以用户友好的方式向用户报告失败的正确方法是什么?
我应该为每个例外情况都发明自己的消息,还是有办法获得本地化的、用户友好的消息,可以逐字呈现给用户?
编辑
我在问.NET 本身是否能够为我提供一个我可以呈现的描述性字符串(并且与其他.NET 程序一致)。我知道我可以自己卷起来,但如果有标准的替代方案,我想避免这种情况。
考虑一个 C# GUI 应用程序,它使用 aFileStream
来读取文件,由用户通过“打开文件”对话框选择。
如果读取失败并出现异常之一,以用户友好的方式向用户报告失败的正确方法是什么?
我应该为每个例外情况都发明自己的消息,还是有办法获得本地化的、用户友好的消息,可以逐字呈现给用户?
我在问.NET 本身是否能够为我提供一个我可以呈现的描述性字符串(并且与其他.NET 程序一致)。我知道我可以自己卷起来,但如果有标准的替代方案,我想避免这种情况。
您可以拥有一组可本地化的用户异常,其中一个是 say FileUploadError
。您可以在此处放置本地化的一般信息。抛出一些技术细节可能有点挑战性,因为很难在技术细节和用户修复错误需要采取的简单步骤之间取得适当的平衡。
我的建议是:
FileUploadErrorException
如果您正在捕获由 .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);
}
异常消息本质上是技术性的,描述了哪里出了问题(在实现级别),而不是如何解决最终用户的问题。另一方面,向用户显示错误消息的目的是解释什么失败以及采取什么措施来解决问题。异常消息和最终用户错误消息的目的不同,也不是为相同的受众编写的。
因此,为了获得良好的用户体验,最好将这些异常映射到本地化的用户友好建议,以解决该问题。当然,对于技术用户来说,拥有一些可以提供异常详细信息的诊断功能可能会很好(在这种情况下,英语异常消息并不重要——英语确实是世界上的技术语言),或者只是指出将它们记录到包含所有详细信息的日志中。但只是向最终用户抛出异常消息,即使是本地化的,也可能会让他们感到困惑。
出于这个原因,我认为本地化异常消息没有多大用处。.NET 框架确实为主要语言提供了本地化异常消息,但我认为这更多是因为有些开发人员使用这些语言作为他们的基础语言,并且不一定能很好地掌握英语。因此,这些本地化异常消息的受众仍然是开发人员,而不是使用 .NET 构建的软件产品的最终用户。