向用户报告异常消息时的最佳实践答案

【问题标题】：Best practices when reporting exception messages to the user向用户报告异常消息时的最佳实践
【发布时间】：2023-04-10 07:36:01
【问题描述】：

在我的 ASP.NET MVC 应用程序中，我不想向用户报告所有异常消息。但是我想向用户报告某些类型的异常，所以我创建了一个操作过滤器来确定它是否是这种特定类型的异常，如果是，则显示异常的消息，否则显示一般消息。所以我创建了一个名为 ClientException 的自定义异常。

我的过滤器看起来像这样：

    if (filterContext.Exception is ClientException)
         message = filterContext.Exception.Message.Replace("\r", " ").Replace("\n", " ");
   else
        message = "An error occured while attemting to perform the last action.  Sorry for the inconvenience.";

    filterContext.HttpContext.Response.Status = "500 " + message;

我读到了http://blogs.msdn.com/b/kcwalina/archive/2007/01/30/exceptionhierarchies.aspx，作者建议使用现有的 .NET 异常类型来报告使用错误。但是，通过引入我的自定义异常，我只需要在我的过滤器中进行一次检查。我的方法好吗？

【问题讨论】：

标签： c# .net asp.net asp.net-mvc exception

【解决方案1】：

我喜欢这种方法有几个原因。

首先，它安全地失败了。如果有人没有明确抛出 ClientException，则不会报告异常详细信息。忘记显示某事比不小心显示某事的问题要小。

其次，它允许决定是否在适当的位置显示异常。例如，并非所有 IOExceptions 都会显示。有些可能是，有些则不会。可以在调用堆栈中的任何位置捕获和转换特定的异常，以便可以在已知正确的地方进行转换。

这两件事加在一起意味着未来的开发人员不会不恰当地更改要显示的整个异常类，或者认为某些内容实际上不会显示。

此外，使用特定异常类型的目的是确定以后要采取什么行动来响应该异常。 “向用户显示此消息”是一个非常好的指定操作。一旦做出决定，那么异常的确切性质就完全无关紧要了。（当然，为了记录目的，最初的问题可能放在 InnerException 属性中。）

所以，在我看来，这是一个很好的设计。

【讨论】：

【解决方案2】：

您的方法很好 IMO，但还有其他选择。（我们是软件开发人员，所以总是有替代方案。）

您可以利用Exception Data 字典来存储一个标志，指示异常是否是客户端异常。然后你可以让你的过滤器检查标志的存在。

【讨论】：

【解决方案3】：

如果你的方法适合你，那就没问题。您对 Microsoft 博客建议您使用他们的 Exception 类感到惊讶吗？ ;)

但有一些 .NET 库功能和 3rd 方 OSS 东西只能用于 .NET 异常。

为了两全其美，您始终可以将 .NET Exception 对象扩展为您自己的。

【讨论】：

【解决方案4】：

我会根据异常的类型使用不同的阈值，这些阈值将与异常消息相关联。

根据特定的阈值逻辑，您可能想要决定是否显示异常。

【讨论】：

【解决方案5】：

我对此解决方案的担忧是，这些异常很可能通常由业务层中的对象（或 MVC 术语中的模型对象）引发。您描述的用法确实是我认为的演示问题。

通常，您需要重新抛出模型中的任何异常，只是为了传达异常是否可以向用户公开。您希望用户如何处理这些信息？如果用户可以修复这种情况，也许不应该有异常来指示状态开始？

我会坚持在每个案例中捕捉特定的例外情况，并在现场做出演示决定。不过，您可能会发送一个异常，被捕获，用作视图的模型。我仍然会让控制器决定，而不是由谁抛出异常。

【讨论】：