8 
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(...)。

4

3 回答 3

7

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

（一）回答。这不是好的做法。您应该使用异常生成器方法，而不是直接抛出 HttpException。

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

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

(3)做。尽可能使用基类库异常，并且仅在绝对没有满足所需要求的基异常时才创建自​​定义异常。创建自定义异常会增加更深的异常层次结构，这会在不需要的情况下增加调试难度，增加额外的性能开销，还会给代码库增加额外的膨胀。

(4)不要。抛出基类 System.Exception。请改用特定的异常类型。

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

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

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

任何阅读过 .NET 开发系列中的框架设计指南的人都会知道这些做法，它们是非常好的做法。这些正是构建 .NET 框架和 MVC 的实践。

于 2012-04-19T05:01:59.970 回答
2

如果您是首先抛出异常的人，那么是的 - 没关系。但是，如果你捕获一个HttpException然后尝试抛出一个PageNotFoundException，你应该把原来的异常作为 InnerException。

于 2012-04-19T04:56:53.967 回答
1

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

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

基本上，像这样的结构会增加项目工作所需的适应时间，并且应该以这种成本最小化的方式进行处理（在一个容易找到的中央共享对象库中充分可见，而且还不太杂乱） .

另一方面，如果您要寻找的本质上是工厂模式的好处，那么集中生成 HttpExceptions 肯定是有价值的；如果这就是你想要摆脱的（throw ExceptionFactory.NewPageNotFound()），那么它可能值得一试。

于 2012-04-19T05:01:36.353 回答