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

, , , ,

Yan Cui

I help clients go faster for less using serverless technologies.

Table of Content
The Problem
Proposed Solution
Before you go…

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:

/// <summary>
/// A simple trace attribute which writes trace statements for a method to the console
/// </summary>
[Serializable]
public class TraceAttribute : OnMethodBoundaryAspect
{
public override void OnEntry(MethodExecutionArgs args)
{
var methodName = GetMethodName(args.Method);
args.MethodExecutionTag = methodName;
Console.WriteLine("Entering {0}", methodName);
base.OnEntry(args);
}
public override void OnSuccess(MethodExecutionArgs args)
{
Console.WriteLine("{0} executed successfully", args.MethodExecutionTag);
base.OnSuccess(args);
}
public override void OnException(MethodExecutionArgs args)
{
Console.WriteLine("{0} excepted : {1}", args.MethodExecutionTag, args.Exception);
base.OnException(args);
}
private string GetMethodName(MethodBase method)
{
if (method.IsGenericMethod)
{
var genericArgs = method.GetGenericArguments();
var typeNames = genericArgs.Select(t => t.Name);
return string.Format("{0}<{1}>", method.Name, String.Join(",", typeNames));
}
return method.Name;
}
}
/*##############################################################################
################# THIS ILLUSTRATES THE ATTRIBUTE DOES NOT ######################
################# WORK AS EXPECTED ON ASYCN METHODS ######################
################################################################################*/
class Program
{
static void Main(string[] args)
{
Start().Wait();
Console.WriteLine("All done");
Console.ReadKey();
}
private static async Task Start()
{
Foo();
await FooAsync();
AsyncVoid();
try
{
Boo();
}
catch
{
}
try
{
await BooAsync();
}
catch
{
}
}
[Trace]
private static void Foo()
{
}
[Trace]
private static void Boo()
{
throw new Exception("boom!");
}
[Trace]
private static async void AsyncVoid()
{
await Task.Delay(1000);
Console.WriteLine("AsyncVoid done.");
}
[Trace]
private static async Task FooAsync()
{
await Task.Delay(1000);
Console.WriteLine("FooAsync done.");
}
[Trace]
private static async Task BooAsync()
{
await Task.Delay(1000);
throw new Exception("async boom!");
}
}
/*#########################################################
############ OUTPUTS FROM THE ABOVE ###################
#########################################################
Entering Foo
Foo executed successfully <-- works on normal non-async methods
Entering FooAsync
FooAsync executed successfully <-- async method is reported to be successful before the task completes
FooAsync done. <-- the task actually completes here
Entering AsyncVoid
AsyncVoid executed successfully <-- same problem as above, this time for 'async void' methods
Entering Boo
Boo excepted : System.Exception: boom! <-- exception is traced as expected for normal non-async method
at ConsoleApplication8.Program.Boo() in c:\Users\theburningmonk\Documents\Vis
ual Studio 2012\Projects\ConsoleApplication8\ConsoleApplication8\Program.cs:line
48
Entering BooAsync
BooAsync executed successfully <-- BooAsync actually excepted but is not reported here
AsyncVoid done. <-- the 'async void' actually finishes here
All done
*/
view raw gistfile1.cs hosted with ❤ by GitHub

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:

[Serializable]
public abstract class OnAsyncMethodBoundaryAspect : OnMethodBoundaryAspect
{
public override bool CompileTimeValidate(MethodBase method)
{
// make sure we have access to the method info so we can check the return type
var methodInfo = method as MethodInfo;
if (methodInfo == null)
{
throw new Exception("method is not MethodInfo");
}
// make sure the method returns Task or Task<T>
if (!typeof(Task).IsAssignableFrom(methodInfo.ReturnType))
{
var message = string.Format(
"[{0}] can only be applied to a method which returns Task or Task<T>",
GetType().Name);
throw new Exception(message);
}
return base.CompileTimeValidate(method);
}
public override void OnExit(MethodExecutionArgs args)
{
var returnedTask = (Task)args.ReturnValue;
returnedTask.ContinueWith(t => OnTaskFinished(t, args));
returnedTask.ContinueWith(t => OnTaskFaulted(t, args), TaskContinuationOptions.OnlyOnFaulted);
returnedTask.ContinueWith(t => OnTaskCompletion(t, args), TaskContinuationOptions.OnlyOnRanToCompletion);
}
/// <summary>
/// Handler for when the preceding task returned by the method has finished, regardless whether or
/// not the task faulted or ran to completion.
/// </summary>
public abstract void OnTaskFinished(Task precedingTask, MethodExecutionArgs args);
/// <summary>
/// Handler for when the preceding task returned by the method has faulted.
/// </summary>
public abstract void OnTaskFaulted(Task precedingTask, MethodExecutionArgs args);
/// <summary>
/// Handler for when the preceding task returned by the method has run to completion.
/// </summary>
public abstract void OnTaskCompletion(Task precedingTask, MethodExecutionArgs args);
}
view raw gistfile1.cs hosted with ❤ by GitHub

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

[Serializable]
public class TraceAsyncAttribute : OnAsyncMethodBoundaryAspect
{
public override void OnEntry(MethodExecutionArgs args)
{
var methodName = GetMethodName(args.Method);
args.MethodExecutionTag = methodName;
Console.WriteLine("Entering {0}", methodName);
base.OnEntry(args);
}
public override void OnTaskFinished(Task precedingTask, MethodExecutionArgs args)
{
Console.WriteLine("{0} finished", args.MethodExecutionTag);
}
public override void OnTaskFaulted(Task precedingTask, MethodExecutionArgs args)
{
Console.WriteLine("{0} excepted : {1}", args.MethodExecutionTag, precedingTask.Exception);
}
public override void OnTaskCompletion(Task precedingTask, MethodExecutionArgs args)
{
Console.WriteLine("{0} executed successfully", args.MethodExecutionTag);
}
private string GetMethodName(MethodBase method)
{
if (method.IsGenericMethod)
{
var genericArgs = method.GetGenericArguments();
var typeNames = genericArgs.Select(t => t.Name);
return string.Format("{0}<{1}>", method.Name, String.Join(",", typeNames));
}
return method.Name;
}
}
/*##############################################################################
############## THIS ILLUSTRATES THE ASYNC ATTRIBUTE DOES ###################
############## WORK AS EXPECTED ON ASYCN METHODS ###################
################################################################################*/
class Program
{
static void Main(string[] args)
{
Start().Wait();
Console.WriteLine("All done");
Console.ReadKey();
}
private static async Task Start()
{
Foo();
await FooAsync();
try
{
Boo();
}
catch
{
}
try
{
await BooAsync();
}
catch
{
}
}
[Trace]
private static void Foo()
{
}
[Trace]
private static void Boo()
{
throw new Exception("boom!");
}
[TraceAsync]
private static async Task FooAsync()
{
await Task.Delay(1000);
Console.WriteLine("FooAsync done.");
}
[TraceAsync]
private static async Task BooAsync()
{
await Task.Delay(1000);
throw new Exception("async boom!");
}
}
/*#########################################################
############ OUTPUTS FROM THE ABOVE ###################
#########################################################
Entering Foo
Foo executed successfully
Entering FooAsync
FooAsync done.
Entering Boo
FooAsync finished <-- OnTaskFinished is executed correctly after the Task had finshed
FooAsync executed successfully <-- OnTaskCompletion is executed correctly too, not that OnTaskFaulted is not fired
Boo excepted : System.Exception: boom!
at ConsoleApplication8.Program.Boo() in c:\Users\theburningmonk\Documents\Vis
ual Studio 2012\Projects\ConsoleApplication8\ConsoleApplication8\Program.cs:line
46
Entering BooAsync
BooAsync finished <-- OnTaskFinished is executed correctly after the Task had finished
BooAsync excepted : System.AggregateException: One or more errors occurred. --->
System.Exception: async boom!
at ConsoleApplication8.Program.<BooAsync>d__6.MoveNext() in c:\Users\theburni
ngmonk\Documents\Visual Studio 2012\Projects\ConsoleApplication8\ConsoleApplicat
ion8\Program.cs:line 60
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
--- End of inner exception stack trace ---
---> (Inner Exception #0) System.Exception: async boom!
at ConsoleApplication8.Program.<BooAsync>d__6.MoveNext() in c:\Users\theburni
ngmonk\Documents\Visual Studio 2012\Projects\ConsoleApplication8\ConsoleApplicat
ion8\Program.cs:line 60
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)<
--- <-- OnTaskFaulted is fired after the Task faulted, not that OnTaskCompletion is not fired
All done
*/
view raw gistfile1.cs hosted with ❤ by GitHub

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

Whenever you’re ready, here are 3 ways I can help you:

  1. Production-Ready Serverless: Join 20+ AWS Heroes & Community Builders and 1000+ other students in levelling up your serverless game. This is your one-stop shop for quickly levelling up your serverless skills.
  2. I help clients launch product ideas, improve their development processes and upskill their teams. If you’d like to work together, then let’s get in touch.
  3. Join my community on Discord, ask questions, and join the discussion on all things AWS and Serverless.

5 thoughts on “AOP – using PostSharp attributes with async Task/Task<T> methods”

  3. Joe Enos

    Actually, I think it needs to be:
    (methodInfo.ReturnType.IsGenericType && methodInfo.ReturnType.GetGenericTypeDefinition() != typeof(Task))

    The return type of the method might be typeof(Task), which is never equal to typeof(Task), so you’d need to do this generic conversion.

  4. Joe Enos

    Stupid WordPress comment cleaner thing…

    There are angle brackets after the Tasks in that previous comment (I’ll put square brackets here):

    (methodInfo.ReturnType.IsGenericType && methodInfo.ReturnType.GetGenericTypeDefinition() != typeof(Task[]))

    The return type of the method might be typeof(Task[Foo]), which is never equal to typeof(Task[]), so you’d need to do this generic conversion.

  5. theburningmonk

    @Joe Enos – you’re right, intellisense got the better of me there! In the version I ended up using I actually simplified it and store a bool flag so to avoid doing these checks at runtime:

    protected bool IsAsync { get; set; }

    public override void CompileTimeInitialize(MethodBase method, AspectInfo aspectInfo)
    {
    var methodInfo = method as MethodInfo;
    if (methodInfo == null)
    {
    throw new Exception(“MethodInfo is null”);
    }

    IsAsync = typeof(Task).IsAssignableFrom(methodInfo.ReturnType);

    base.CompileTimeInitialize(method, aspectInfo);
    }

    so that my attribute is compatible with both async and sync methods, and at runtime, I only hook up the task continuations for async methods, can’t share the rest of that class, but you should get the idea easy enough I suppose.

Leave a Comment

Your email address will not be published. Required fields are marked *