2

这听起来像是一个愚蠢的问题，但我想收集一些关于此的意见。我习惯于看到两种处理异常消息的方式。首先有一个简单的模式，您可以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 中……）是针对谁的呢？最终用户还是程序员？

谢谢，

4

4 回答 4

2

不，我觉得异常详细信息（Message 和 StackTrace）最好留到日志中。通常，异常文本过于技术性而无法向用户显示，实际上可能会给恶意用户提供可用于入侵或以其他方式攻击系统的信息。

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

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

于 2013-08-01T16:01:12.267 回答
1

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

于 2013-08-01T16:02:38.640 回答
1

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

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

对于所有未处理的异常，您应该有一个标准化的用户友好消息，礼貌地告诉他们出现了问题，并且可能显示来自该方法的错误代码，这对他们没有意义，对您来说意味着什么。

最重要的是，如果您正在记录所有应该做的异常，您也许可以向用户提供错误的日志编号，以帮助您跟踪问题。

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

于 2013-08-01T16:03:06.763 回答
1

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

于 2013-08-01T16:07:31.977 回答