Question

public class PageNotFoundException : HttpException
{
    public PageNotFoundException()
        : base(404, "HTTP/1.1 404 Not Found")
    {

    }
}

这个想法是，而不是每次都输入这个

throw new HttpException(404, "HTTP/1.1 404 Not Found")

我宁愿写

throw new PageNotFoundException();

我打算添加一个包含innerException的重载，但是我永远不会在try / catch块中使用它。

你会考虑这个好习惯吗？
即。继承异常并将硬编码信息传递给base（...）。

Answer 1

我决定重写我的答案以特定于您的实际问题，并且从更广泛的意义上说，MVC应用程序不是这些最佳实践适用的唯一内容。

（1）回答。这不是好习惯。您应该使用异常构建器方法，而不是直接抛出HttpException。

public static void ThrowPageNotFoundException() {
    throw new HttpException((Int32)HttpStatusCode.NotFound, "HTTP/1.1 404 Not Found");
}

（2） DO 。使用异常构建器方法（例如，我提供的代码）。这允许您避免拥有自己的异常类型的额外性能成本，并允许它内联。抛出异常的成员不会被内联。这将是方便投掷的正确替代品。

（3） DO 。尽可能使用基类库异常，并且只有在绝对没有满足所需要求的基本异常时才创建自定义异常。创建自定义异常会增加更深层次的异常层次结构，这会使调试更加困难，增加额外的性能开销，并为代码库增加额外的膨胀。

（4）不要。抛出基类System.Exception。改为使用特定的异常类型。

（5）不要。为方便起见，创建自定义异这不是自定义异常的好理由，因为异常本质上是昂贵的。

（6）不要。创建自定义异常只是为了拥有自己的异常类型。

（7）不要。抛出可以通过更改调用代码来避免的异常。这表明您在API中存在可用性错误，而不是实际问题。

任何阅读过.NET开发系列框架设计指南的人都会知道这些实践，并且这些实践非常好。这些是构建.NET框架的实践，以及MVC。

Answer 2

如果你是第一个抛出异常的人，那么是的 - 没关系。但是，如果您捕获HttpException然后尝试抛出PageNotFoundException，则应将原始异常作为InnerException。

Answer 3

虽然这是你自己的代码中一个很好的构造供你自己使用，但一个考虑因素是它可以按照惯例促进编码，这在你与其他/新开发人员打交道时会很危险。

在你自己的库中，如果你在抛出404 HttpException时抛出一个PageNotFoundException是一致的，那么对catch (PageNotFoundException)更有意义。但是，当您开始使用没有自定义异常的其他库时，您将错过其他代码抛出的404 HttpExceptions。同样，如果您有其他开发人员在以后做出贡献（或者甚至将来自己添加），可能会错过PageNotFoundExceptions被大多数功能捕获的内容，并且可能会在新模块中抛出新的404 HttpExceptions ，同样不会被复制/粘贴的呼叫代码捕获。

基本上，这样的构造会增加处理项目所需的适应时间，并且应该以这样的方式处理这个成本（在一个易于找到的中央共享对象库中已经足够可见）太杂乱了。）

另一方面，如果您正在寻找的是工厂模式的好处，那么集中生成HttpExceptions肯定有价值;如果那是你想要摆脱它的东西（throw ExceptionFactory.NewPageNotFound()），那么它可能值得去做。

这是自定义异常的好习惯吗？

3 个答案: