Note that there are some explanatory texts on larger screens.

plurals
  1. PODebugging Exceptions in Async Code
    text
    copied!<p>Back when I used synchronous methods in code using ASP.NET MVC 3, if an exception was thrown, it wasn't hard to figure out where it came from in my exception filter. Just looking at the stack trace was enough.</p> <p>When an <code>async</code> method in ASP.NET Web API throws an exception, however, the exception details are less useful, since the stack trace doesn't show where the exception was thrown from:</p> <pre><code>System.ArgumentException: title must not be empty. Parameter name: title at System.Web.Http.Filters.ActionFilterAttribute.&lt;CallOnActionExecutedAsync&gt;d__1.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Web.Http.Controllers.ActionFilterResult.&lt;ExecuteAsync&gt;d__2.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Web.Http.ApiController.&lt;InvokeActionWithExceptionFilters&gt;d__1.MoveNext() </code></pre> <p>Currently, I have to look at all the exceptions with this message and guess which one was thrown based on the request URI and what's going on behind the scenes, or try and reproduce the bug locally with a debugger attached.</p> <p>MSDN has an article detailing a couple strategies for getting a casualty chain: <a href="http://msdn.microsoft.com/en-us/magazine/jj891052.aspx3">http://msdn.microsoft.com/en-us/magazine/jj891052.aspx3</a>. From my understanding, I have two choices:</p> <ul> <li>Use System.Diagnostics.EventListener and take a performance hit at run-time</li> <li>Create an extension method and use it with every <code>await</code> call</li> </ul> <p>Is there a better way to log more helpful details about what threw this exception? Having the casualty chain would be nice, but just getting the exception source would be fine (what type and method this was thrown in).</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload