0

I have little mess up things with tasks. So please explain me which is the main difference between a Task with signature vs no-signature. Example 

 async Task myTaskAsync();
 vs
 async Task myTask();

Is there any difference if i will not include Async in my end of fuction?

jazb
  • 5,498
  • 6
  • 37
  • 44
ddd
  • 85
  • 2
  • 10
  • 1
    No, it is just a naming convention. You can name it as you wish – Tomas Chabada Nov 15 '18 at 08:27
  • 1
    No difference. It is just recommended to include it so you can spot immediatly it's awaitable / async (TPL). – Fildor Nov 15 '18 at 08:27
  • Thank you for the asnwer. One last question, is it better to use async task instead async void? – ddd Nov 15 '18 at 08:31
  • async void is for EventHandlers. https://blog.stephencleary.com/2012/02/async-and-await.html => See section "Return Types" – Fildor Nov 15 '18 at 08:31
  • 2
    The reason why you want to name it with Async is just for your knowledge or other developers who may inherit your code some day. No other purpose for the naming. As best practice, always name your functions appropriately. – Casperonian Nov 15 '18 at 08:31
  • Sure, always prefer using async Task over async void. Async void can cause exception to be unhandled even in try section – Tomas Chabada Nov 15 '18 at 08:32
  • @TomasChabada also, they are not awaitable. Steven Cleary writes excellent blogs about all this. "Never" is not correct, though. For async event handlers, it's absolutely appropriate. – Fildor Nov 15 '18 at 08:34
  • Yes, therefore I wrote he should always prefer it. But, there are situations where this is not possible, then, the question does not make a sense – Tomas Chabada Nov 15 '18 at 08:37
  • @TomasChabada AH, I see. Then I misread your comment. Nevermind. – Fildor Nov 15 '18 at 08:37

2 Answers2

2

It does not matter regarding the behavior of the function if you add the "Async" suffix or not.

It does matter regarding the perception of your API by clients.

This naming convention is broadly adopted, so you do yourself and others a favor using it.

BTW: If that API in question already contains legacy async functions (non-TAP) that are named "xxxAsync", then it is recommended to use "xxxTaskAsync" instead.

Fildor
  • 14,510
  • 4
  • 35
  • 67
  • A similar question has been answered here: https://stackoverflow.com/a/24627122/982149. It's not exactly a dupe, but may be interesting for you. It includes a statement by Steven Toub himself. – Fildor Nov 15 '18 at 08:57
1

Yes, it matters when you care about your code design, for example:

public interface IMyService
{
    Task<int> GetWeightAsync();
    int GetWeight();
}

In this case you support both: async and non-async version for users of this interface, so they can decide which path they want to choose.

C# is designed polymorphic, but in case of async, it is just way to fake it. The compiler will still complain if signature will be same except return value, so people decided to add suffix 'Async' at the end.

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
eocron
  • 6,885
  • 1
  • 21
  • 50
  • 1
    It is still just a _convention_. Naming it "Herbert()" won't change anything (but the name). – Fildor Nov 15 '18 at 08:30
  • Oh, the name in programming means more than logic itself. It often describes logic, so if you name it Herbert() you will purposely name it so it contains something related to Herbert. Just like we use Async to describe behavior of polimorphic function (because we need to avoid compilation error on linkage). – eocron Nov 15 '18 at 08:34
  • But it will not behave differently. That's what I am saying. – Fildor Nov 15 '18 at 08:36
  • Yes, name will not define behavior, as I said, it's just one of necessity of C# when method just needs to be with different name. In fact it's name should be the same and compiler should have decided itself what to choose and when, but...real world, we line in it. – eocron Nov 15 '18 at 08:41