0

Here in the company I work for I'm facing a problem with the .NET/C# async/await feature regarding methods that returns nothing (void).

The project guidelines stands that the async/await should always be used, but IMO the are some cases where I need to use void methods and the async/await seems to not work properly with these kind of methods.

For example, if I adopt the command/query pattern that stands that methods that cause state change shouldn't return anything, just queries (that do not change state) is that returns.

What options do I've? I don't want to give up programming patterns just because some language feature like async/wait seems to not work with void methods.

The most problematic thing with async/async x void method is that the exceptions are discarded in the async context.

Cœur
  • 37,241
  • 25
  • 195
  • 267
  • 1
    If you have to use void - use void. It's not exactly true that "async\await not work with void methods". See here also: http://stackoverflow.com/a/12144426/5311735 – Evk Jun 02 '16 at 21:19
  • 5
    "The project guidelines stands that the async/await should always be used" this makes me think whoever designed those guidelines have absolutely no idea about c# programming. You need to understand how async/await works to understand your problem. Read up the MSDN: https://msdn.microsoft.com/en-us/library/mt674882.aspx – Camilo Terevinto Jun 02 '16 at 21:20
  • 1
    how about just returning Task without no type result inside ? That's exactly the same as void, but it's the standard for when using asynchronous programming with C# – Kevin Avignon Jun 02 '16 at 21:22
  • Yes, it is a dup really, BTW thanks for all the answers!!! You all helped me a lot! –  Jun 02 '16 at 21:29

1 Answers1

5

The async equivalent of a method that returns int is a method that returns Task<int>. The async equivalent of a method that returns void is a method that returns Task. So you should make your asynchronous "void" methods return Task. Easy peasy!

For example, if I adopt the command/query pattern that requires that methods that cause state change shouldn't return anything, just queries (that do not change state) return values.

Sure. The async equivalent of that is "methods that cause asynchronous state change should return Task, and methods that asynchronously compute values should return Task<T>." The Task is the task of performing the state change, and the Task<T> is the task of computing the T value.

I don't want to give up programming patterns just because some language feature like async/wait seems to not work with void methods.

If you want to use asynchrony, you're going to have to consistently apply asynchronous logic across your design patterns. A design pattern that requires void in synchronous code must require Task in asynchronous code.

The project guidelines stands that the async/await should always be used,

I sincerely hope those guidelines continue on with "... for all IO or processor bound computations that could possibly take more than 30 ms". Making every method in a program asynchronous for no reason sounds like a mess. Asynchrony is there to tame latency; if you haven't got a problem with latency then don't use it.

Eric Lippert
  • 647,829
  • 179
  • 1,238
  • 2,067