Question

这可能听起来像一个愚蠢的问题，但我想就此收集一些意见。我习惯看到两种处理异常消息的方式。首先是简单模式，您可以直接向用户显示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类的Message属性（在C＃中，Java ...）？最终用户还是程序员？

谢谢，

Answer 1

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

因此，我会针对有意义但不是实际技术细节的不同例外选择适当的措辞。

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

Answer 2

这个问题实际上取决于您的受众群体以及您希望为其提供的信息类型。对于大多数最终用户来说，ex.message将毫无意义且令人困惑。但是，如果您是专门为程序员或自己编写的，它可能包含一些有用的信息。

Answer 3

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

你应该处理你可以预见的所有例外情况，并提供一个有用的信息："Unable to load users..."或者他们可以根据他们试图达到的任务理解的东西。

对于所有未处理的异常，你应该有一个标准的用户友好消息，礼貌地告诉他们出现了问题，并且可能会显示方法中的错误代码，这对他们来说没有任何意义，对你来说也是如此。

除此之外，如果您要记录您应该执行的所有异常，您可以向用户显示错误的日志编号，以帮助您跟踪问题。

如果您无权访问日志/网站，请在适当时将异常详细信息通过电子邮件发送给您自己/支持小组。

Answer 4

这个问题的答案非常广泛。但简短的回答是，您应该始终尝试向用户展示他理解的内容。 用户友好的消息是要走的路。我不认为异常对新手用户来说足够有用。因此，应该总是尝试向他显示自定义错误消息并为自己保留异常。它们用于诊断错误，您应该有权访问它们而不是用户。

Exception.Message属性应该直接显示给用户吗？

4 个答案: