Suggestion: sync keyword

[osexpert]

Inspired from this: https://stackoverflow.com/questions/64062682/warning-cs1998-this-async-method-lacks-await-operator-correct-way-to-silence

Several incorrect ways to fix CS1998 and at same time change problem flow.
As I see it, the only way to fix CS1998 without changing program flow is to do:

from

async Task<int> Test(bool b)
{
   if (b) throw new Exception();
   return ThisThrowsToo();
}

to

Task<int> Test(bool b)
{
   try
   {
      if (b) throw new Exception();
      return Task.FromResult(ThisThrowsToo());
   }
   catch (Exception e)
   {
      return Task.FromException(e)
   }
}

It is easy, but I think I have never seen this been done correctly. So I suggest a new keyword "sync" that will create this logic automatically, just like a state machine is created from async.

Like this:

sync Task<int> Test(bool b)
{
   if (b) throw new Exception();
   return ThisThrowsToo();
}

[HaloFour]

This feels like more of an abuse of async to get the Task-wrapping of exceptions in non-asynchronous code. Given that the linked StackOverflow answer provides a very simple helper method that does this wrapping for you in a one-liner I don't see why it needs to (or should be) a language feature.

Task<TResult> RunAsTask<TResult>(Func<TResult> func)
{
    try { return Task.FromResult(func()); }
    catch (Exception e) { return Task.FromException<TResult>(e); }
}

public static Task<int> Test1(bool err) => RunAsTask(() =>
{
    if (err)
        throw new InvalidOperationException();
    return GetNum(42);
});

[osexpert]

"This feels like more of an abuse of async to get the Task-wrapping of exceptions in non-asynchronous code"
Not sure what you mean. How can a suggestion to make it easier to correctly remove incorrect use of async be abusing async? This typically happens when implement interfaces that are all Task based, like everything these days.

I now know how to do this correctly. But no one else knows, and people will still:
-ignore the warning
-disabling the warning
-use hacks like await Task.Yield(), await Task.Completed, etc.
-remove async and really try to fix it but forget to handle the exceptions (eg. just using Task.FromResult(..)

[HaloFour]

How can a suggestion to make it easier to correctly remove incorrect use of async be abusing async?

You don't need a language feature for that. You can simply remove the keyword. That will change the behavior of the method, but that should not matter. There is no guarantee, written or implied, that a method that returns a Task or task-like will not throw an exception. The fact that it might, or that it's async at all, is an implementation detail.

This typically happens when implement interfaces that are all Task based

Those interfaces only dictates that those members return Tasks, not that those methods are async or wrap exceptions.

[jnm2]

• remove async and really try to fix it but forget to handle the exceptions (eg. just using Task.FromResult(..)

This one is really insidious sometimes.

[HaloFour]

Sounds like a good candidate for an analyzer with a fixer, can take an async method with that warning and convert it to a sync method that wraps exceptions.

[CyrusNajmabadi]

Or just keep the method async and suppress the warning

[osexpert]

Yes, that is very tempting.

[jnm2]

I do this.

[osexpert]

Ok, I change my suggestion to remove CS1998 instead🤣

[HaloFour]

You can suppress the warning for an entire project via a project property or compiler argument.

https://visualstudiomagazine.com/articles/2017/09/01/hide-compiler-warnings.aspx

I think it's kinda hilarious that this warning on async methods is their example. 😁