是否应直接向用户显示Exception.Message属性

本文关键字：显示 Exception Message 属性 用户 是否 | 更新日期: 2023-09-27 18:26:00

这听起来可能是一个愚蠢的问题，但我想收集一些关于这方面的信息。我已经习惯了处理异常消息的两种方式。首先是一个简单的模式，您可以直接向用户显示Message：

try
{
    service.Update();
}
catch (Exception ex)
{
    ShowMessage(ex.Message);
}

处理异常的另一种方法是将强类型异常视为由"控制器"类（或处理向用户推送信息的任何代码）解释的东西：

try
{
    service.Update();
}
catch (NetworkException ex)
{
    ShowMessage("Network is unavailable.");
}
catch (Exception ex)
{
    ShowMessage("Something went wrong with the update.");
}

第一种方法要求异常使用的每个消息（无论是由调用代码在构造函数中传递的还是在强类型异常内部管理的）都是"用户就绪"的（干净、正确的公式化和本地化等）。第二种方法将这一责任转移到控制器代码。此外，它可能需要有非常特定的强类型异常，以确保每个catch块都能够正确地解释它们。

那么Exception类（在C#、Java…中）的Message属性是针对谁的呢？最终用户还是程序员？

谢谢你，

是否应直接向用户显示Exception.Message属性

不，我觉得异常细节（Message和StackTrace）最好留给日志。通常情况下，异常文本技术性太强，无法显示给用户，并且实际上可能会向恶意用户提供可用于破解或以其他方式攻击系统的信息。

因此，我会为不同的例外选择合适的措辞，这些措辞是有意义的，但不是实际的技术细节。

当然，如果这是一个针对特定技术受众的技术工具，这可能会改变事情（比如Toad等数据库工具可能会选择显示Oracle异常的详细信息，等等）。但总的来说，我会避免它。

这个问题实际上取决于你的受众是谁以及你想向他们提供什么类型的信息。对于大多数最终用户来说，ex.message将是毫无意义和令人困惑的。然而，如果你是专门为程序员或自己写的，它可能包含一些有用的信息。

这个问题很难回答。但简短的回答是，您应该始终尝试向用户展示他所理解的用户友好消息是最好的选择。我认为对于新手用户来说，例外情况还不够有用。因此，应该始终尝试向他显示自定义错误消息，并为自己保留异常。它们用于诊断错误，您应该可以访问它们，而不是用户。

首先，用户永远不应该看到粗糙的异常消息。

你应该处理你能预见到的所有异常，并给出一个有用的信息："Unable to load users..."或他们能根据他们试图实现的任务理解的东西。

对于所有未处理的异常，您应该有一条标准的用户友好消息，礼貌地告诉他们出了问题，并可能显示该方法的错误代码，这对他们和您来说毫无意义。

除此之外，如果您正在记录所有异常（您应该这样做），您可以向用户提供错误的日志编号，以帮助您跟踪问题。

如果合适，如果您无法访问日志/网站，请随时通过电子邮件将异常详细信息发送给您自己/支持团队。

相关文章：