Question

在我的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异常类型来报告使用错误。但是，通过引入我的自定义异常，我只需要在我的过滤器中进行一次检查。我的方法还可以吗？

Answer 1

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

首先，它安全失败。如果某人没有明确抛出ClientException，则不会报告异常详细信息。忘记显示某些东西比意外显示某些东西要小。

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

这两件事在一起意味着未来的开发人员不会不恰当地改变要显示的整类异常，或者认为某些东西在实际存在时不会显示。

此外，使用特定异常类型的目的是稍后确定响应该异常应采取的操作。 “向用户显示此消息”是一个非常好的指定操作。一旦做出决定，那么例外的确切性质就完全不可信了。（当然，原始问题可以放在InnerException属性中，用于记录目的。）

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

Answer 2

你的方法很好IMO但有其他选择。（我们是软件开发人员，因此总有其他选择。）

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

Answer 3

如果您的方法适合您，那么它很好。您是否对Microsoft博客建议您使用其Exception类感到惊讶？ ;）

但是有一些.NET库功能和第三方OSS的东西只适用于.NET异常。

为了充分利用这两个方面，您始终可以将.NET Exception对象扩展为您自己的对象。

Answer 4

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

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

Answer 5

我对此解决方案的担忧是，很可能这些异常通常会被业务层中的对象（或MVC术语中的模型对象）抛出。您描述的用法实际上是我认为是演示文稿的关注点。

通常，您需要重新抛出模型中的任何异常，只是为了通知异常是否可以向用户公开。您希望用户对这些信息做些什么？如果用户可以解决这种情况，那么应该没有异常来表示状态开始？

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

向用户报告异常消息时的最佳做法

5 个答案: