If my Web API application is going to return an error to a client, I want to know about it.
I want to set up something like ELMAH to notify me when the problem occurs, and I want full details of the error, including exception stack trace, logged on the server.
In MVC, the __Application_Error__ event is how you achive this, but in Web Api this event often isn't triggered because exceptions are converted into **HttpResponseMessage**s higher in the call stack, and because some error conditions create a **HttpResponseMessage** directly without using an exception. One source of this is __HttpControllerDispatcher.SendAsync__, which catches all exceptions and turns them into error responses, discarding the exception information.
Here are some examples of exceptions that I am interested in handling:
* Exceptions thrown from action methods and action filters
* Exceptions thrown when creating a controller instance
* Exceptions due to routing errors, bad requests, authentication problems, and invalid OData queries
* Exceptions thrown when an IQueryable returned by an action method fails to execute
* Exceptions thrown by custom message handlers and formatters
When I started using Web API, I was surprised when my __Application_Error__ handler did not pick up an action method exception. I added a global __ExceptionFilterAttribute__ to take care of that, but then found several other categories of errors that could be returned to the client and still leave silence in the server logs.
In a production environment, relying on clients to report errors and having no error information available on the server will make diagnosing problems reactive and difficult.
Please provide a global error handling event for Web API, so that error details can be logged and notifications sent. The event should provide access to unhandled exceptions and non-success **HttpResponseException**s and **HttpResponseMessage**s. In the case of **HttpError** objects created from an exception, the exception details should be retained for the error handling event.
Comments: I would like to be able to have both IIS custom errors for normal http exceptions AND json formatted exceptions when they emanate from the Web API. At the moment, I have to always return HTTP 200 from the Web API so that the JSON formatted response does not get hijacked by IIS (e.g., returning a 500 http status code will mean IIS will override my JSON output with a custom html message, which is what I want for all other scenarios other than WEB API interactions). Also, the problem is, sometimes there's a deserialization exception that occurs further up the stack from my actual Web API code (usually the deferred invocation of a LINQ query)... I cannot intercept this exception and return a HTTP 200 manually to avoid the IIS override issue, so in this case Web API will return a 500 which subsequently gets overridden by IIS. I have tried using a DelegatingHandler to intercept the Web API request/response cycle so that I could at least log the error, even when IIS overrides the JSON response; but it seems even at that level, no exception has occurred from the deferred LINQ query. If I'm wrong, please could you demonstrate how to work-around this. A lot of people seem to be talking about this, but with no real solutions forthcoming. Many thanks for your help Kris
I want to set up something like ELMAH to notify me when the problem occurs, and I want full details of the error, including exception stack trace, logged on the server.
In MVC, the __Application_Error__ event is how you achive this, but in Web Api this event often isn't triggered because exceptions are converted into **HttpResponseMessage**s higher in the call stack, and because some error conditions create a **HttpResponseMessage** directly without using an exception. One source of this is __HttpControllerDispatcher.SendAsync__, which catches all exceptions and turns them into error responses, discarding the exception information.
Here are some examples of exceptions that I am interested in handling:
* Exceptions thrown from action methods and action filters
* Exceptions thrown when creating a controller instance
* Exceptions due to routing errors, bad requests, authentication problems, and invalid OData queries
* Exceptions thrown when an IQueryable returned by an action method fails to execute
* Exceptions thrown by custom message handlers and formatters
When I started using Web API, I was surprised when my __Application_Error__ handler did not pick up an action method exception. I added a global __ExceptionFilterAttribute__ to take care of that, but then found several other categories of errors that could be returned to the client and still leave silence in the server logs.
In a production environment, relying on clients to report errors and having no error information available on the server will make diagnosing problems reactive and difficult.
Please provide a global error handling event for Web API, so that error details can be logged and notifications sent. The event should provide access to unhandled exceptions and non-success **HttpResponseException**s and **HttpResponseMessage**s. In the case of **HttpError** objects created from an exception, the exception details should be retained for the error handling event.
Comments: I would like to be able to have both IIS custom errors for normal http exceptions AND json formatted exceptions when they emanate from the Web API. At the moment, I have to always return HTTP 200 from the Web API so that the JSON formatted response does not get hijacked by IIS (e.g., returning a 500 http status code will mean IIS will override my JSON output with a custom html message, which is what I want for all other scenarios other than WEB API interactions). Also, the problem is, sometimes there's a deserialization exception that occurs further up the stack from my actual Web API code (usually the deferred invocation of a LINQ query)... I cannot intercept this exception and return a HTTP 200 manually to avoid the IIS override issue, so in this case Web API will return a 500 which subsequently gets overridden by IIS. I have tried using a DelegatingHandler to intercept the Web API request/response cycle so that I could at least log the error, even when IIS overrides the JSON response; but it seems even at that level, no exception has occurred from the deferred LINQ query. If I'm wrong, please could you demonstrate how to work-around this. A lot of people seem to be talking about this, but with no real solutions forthcoming. Many thanks for your help Kris