AOP – using PostSharp attributes with async Task/Task<T> methods

NOTE: if you’re unfamiliar with how PostSharp works under the hood, I highly recommend that you check out Dustin Davis‘ excellent PostSharp Principles series of blog posts here.

The Problem

The new async/await keywords in C# are pretty awesome, and makes life an awful lot easier when writing asynchronous and non-blocking IO code. However, for those of us who are using frameworks such as PostSharp to deal with cross-cutting concerns we now face a new challenge – the aspects which we have come to rely upon no longer works the way we expect them to when applied on async methods (which returns void, Task or Task<T>), as can be seen from the examples below:

So what’s wrong here?

If you take a look at the code from the above example using a decompiler such as JetBrain’s DotPeek, you’ll see that the normal synchronous version of Foo looks something along the line of:

image

As you can see, the weaved code include calls to the OnEntry, OnSuccess and OnException methods provided by the OnMethodBoundaryAspect class, so everything is as expected here.

For FooAsync however, the picture is a little more complicated:

image

Turns out the C# compiler rewrites async methods into a state machine which means that although the OnSuccess and OnException hooks are still in place, they’re not telling us when the body of the method succeeds or fails but instead, when the state machine creation has succeeded or failed!

image

image

Pretty big bummer, eh?

Proposed Solution

One way (and the best way I can think of for now) to get around this is to have a special aspect which works with methods that return Task or Task<T> and hook up continuations to be executed after the returned tasks had finished. Something similar to the below will do for the on method boundary aspect:

And then you can create a TraceAsync attribute that works for async methods:

As you can see from the output above, our new OnTaskFinished, OnTaskFaulted and OnTaskCompletion hooks are correctly executed after the task returned by the async method had finished, faulted due to exception or ran to completion!

The same approach can also be applied to other built-in aspects such as the MethodInterceptionAspect class.

Before you go…

However, there are a two things you should consider first before jumping into the workaround proposed above.

1. if you look at the output from the previous example carefully, you’ll see that the line “FooAsync finished” came AFTER “Entering Boo” even though from the test code we have awaited the completion of FooAsync before calling Boo. This is because the continuations are executed asynchronously.

If this behaviour is not desirable to you, there is a very simple fix. Back in the OnAsyncMethodBoundAspect class we defined above, simply add TaskContinuationOptions.ExecuteSynchronously to each of the continuations:

image

2. the proposed solution still wouldn’t work with async methods that return void simply because there are no returned Task/Task<T> objects to hook up continuations with. In general though, you should avoid having async void methods as much as possible because they introduce some pitfalls which you really wouldn’t want to find yourself in! I’ve discussed the problem with aysnc void (and some potential workarounds) in a previous post here.

 

I hope this post proves useful to you, and happy PostSharp’ng! I hear some big things are coming in this space Winking smile

C# – beware of async void in your code

In general, when you see async void in your code it’s bad news, because:

  1. you can’t wait for its completion (as mentioned in this post already)
  2. any unhandled exceptions will terminate your process (ouch!)

 

Suppose you have a timer event that fires every once in a while and you want to do some asynchronous processing inside the handler, so you proceed to write something along the lines of:

The fact that your timer event excepted might hurt, that it took your whole process with it is likely to hurt an awful lot more!

Well, what are your options? If you change the handler to return Task instead the code won’t compile because ElapsedEventHandler delegate type specifies a void return type. Annoyed

Two options springs to mind here.

First, you can always just execute the whole block of code synchronously instead.

This is not ideal because it’s going to block the thread whilst it’s waiting for the asynchronous operation to come back, preventing the thread from being used to do other useful work in the mean time.

If you wish to persist with using async-await and just wish to swallow any exceptions then you can consider option two:

In this case, we’ve simply used a continuation (which fires regarded whether the preceding task had faulted) to swallow any exception that had been thrown by the asynchronous operations.

 

Hope this helps, and remember, whenever you see async void in your code it should be triggering off your spider senses!