Is this good practice for a Custom Exception?

Question

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

    }
}

The idea is that rather than typing this each time

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

I'd rather write

throw new PageNotFoundException();

I was going to add an overload for including the innerException however I will never use this in a try/catch block.

Would you consider this good practice?
i.e. Inheriting from an exception and passing hardcoded information to base(...).

Answer 1

I decided to rewrite my answer to be specific to your actual question, and in a more broad sense that an MVC application isn't the only thing these best-practices apply to.

(1) Answer. This is not good practice. You should use a exception builder method instead that throws HttpException directly.

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

(2) DO. Use exception builder methods (eg. the code I provided). This allows for you to avoid the extra performance cost of having your own exception type, and allows for it to be inlined. Members throwing exceptions do not get inlined. This would be the proper substitute for convenience throwing.

(3) DO. Use base class library exceptions whenever possible, and only create a custom exception when there is absolutely no base exception that meets the needed requirements. Creating custom exceptions adds deeper exception hierarchy, which makes debugging harder when it does not need to be, adds extra performance overhead, and also adds extra bloat to your code base.

(4) Do NOT. Throw the base class System.Exception. Use a specific exception type instead.

(5) Do NOT. Create custom exceptions for convenience. This is not a good reason for a custom exception, because exceptions are intrinsically costly.

(6) Do NOT. Create custom exceptions just to have your own exception type.

(7) Do NOT. Throw exceptions that can be avoided by changing the calling code. This would suggest that you have a usability error in the API rather than an actual problem.

Anyone who has read Framework Design Guidelines from the .NET development series will know these practices, and they are very good practices. These are the very practices that the .NET framework was built upon, and MVC as well.