1

I've built a simple REST service using ASP.NET web api.
I've associated one of my controller's method with a custom ActionFilterAttribute, overriding it's OnActionExecuted. On the action filter I use the response about to be sent (actionExecutedContext.Response).
The whole application is associated with a custom ExceptionFilterAttribute overriding OnException used for logging errors.

Now for the problem - when an exception is raised from the controller's method, I've expected one of the two :
1. The OnException will be fired away first, then the OnActionExcuted with an appropriate response.
2. Only the OnExcpetion is invoked, since the action didn't really finished executing.

What actually happens is that the OnActionExecuted is invoked, the response is null, as a result another exception (this time null reference) is raised, caught in the OnException and loggs the wrong exception.

My questions are :
1. Why is the OnActionExecuted is called if an exception has been raised? Shouldn't the OnException be invoked first? An explanation will be appriciated.
2. I understand that OnActionExecuted should be changed, what's the right way to do it? In general do I need to check before doing anything that the actionExecutedContext.Response or the actionExecutedContext.Exception isn't null (besides the obvious check in the OnException methods)? I've based my code in the attributes' actions that there's always a response but apparently not.

Any help would be appriciated, thanks in advance :)!

DotnetProg
  • 790
  • 9
  • 24
  • OnException handlers are part of the response processing pipeline. As such they indeed get invoked after the OnActionExecuting and OnActionExecuted handlers. You can think of the OnAction* pair as surrounding the controller's action method like a try finally block. The [ASP.Net WebApi: HTTP Message Lifecycle](http://www.asp.net/posters/web-api/ASP.NET-Web-API-Poster.pdf) poster paints a nice picture of what runs when/where. – Marjan Venema Nov 09 '13 at 12:18
  • That poster really helps to get things straight in my head! But even from the poster I see that when there's an exception after invoking the action, it should "skip" the OnActionExecuted and Result conversion and go directly to the ExceptionFilter. I understand that you are right (since it actually gets to OnActionExecuted before the OnException) but even the poster doesn't explain it the best way :) So thanks a lot! I think I got an answer for my first question. Any help on the second? – DotnetProg Nov 09 '13 at 12:43
  • Looking at it again, yes, that's how I would read it as well. May still depend on the type of exception. If it is an HttpResponseException it is treated as a "normal" response, and is not considered an unhandled exception. But then the OnException should not be triggered... I think that in OnActionExecuted I would put the check on the exception rather than the response. Response could be unassigned when sending a valid result without a response body (204 No content response). – Marjan Venema Nov 09 '13 at 13:23
  • I'm pretty sure that the exception isn't an HttpResponseException because im 99.99% certain that the exception is being thrown from the DB, since it's the only thing i do in my action being invoked. I rather check the exception too so I'll go with your advice. THX! :) – DotnetProg Nov 10 '13 at 19:51

0 Answers0