Error handling can be messy. While editing the default error pages helps, there are some details you should be aware of.
Essentially, there are two types of errors: an error in your managed code which you can somehow 'catch' using code. Second, there are IIS errors that never make it to your managed code, because the associated handler was never invoked. For example, a request that does not map any routes won't invoke any code, because IIS assumes a static resource was requested.
I suggest these three steps to make error handling a bit more convenient
Don't redirect! redirecting on error violates HTTP. Instead, you should simply return the page in-place using Server.Transfer
or return View("...")
, or by writing to the response stream directly, depending on where the error is handled. Key point: the URL should not change. See, for example http://www.google.com/asdf/asdf
Add and register a global filter that inherits HandleErrorAttribute
and implement your error-handling (and logging) routine. You can make this smart so it returns HTML for HTML requests and JSON for JSON requests, etc.
Configure Remove the default error handlers of IIS to make sure all errors go to the same destination, if this is what you want. This prevents you from the ugly IIS default error pages. You can do that in IIS manager, or in web.config
.