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: @MarkWH (and all others commenting or interested in the issue) It would help if you can share a simple example of the cases you want handled. There are few things we will be able to handle and few that not so easily. For example if your formatter throws during the time where it writes the body out, you are out of luck since the response and headers already went on the wire. Yes you can probably log, but you will have a hard time writing a coherent response to the client. By sharing your specific example(s) we will both be able to plan fixing this bug better and attempt to address your specific issues as well as provide current how to guidance.
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: @MarkWH (and all others commenting or interested in the issue) It would help if you can share a simple example of the cases you want handled. There are few things we will be able to handle and few that not so easily. For example if your formatter throws during the time where it writes the body out, you are out of luck since the response and headers already went on the wire. Yes you can probably log, but you will have a hard time writing a coherent response to the client. By sharing your specific example(s) we will both be able to plan fixing this bug better and attempt to address your specific issues as well as provide current how to guidance.