How to safely call an async method in C# without await

Question

I have an async method which returns no data:

public async Task MyAsyncMethod()
{
    // do some stuff async, don't return any data
}

I'm calling this from another method which returns some data:

public string GetStringData()
{
    MyAsyncMethod(); // this generates a warning and swallows exceptions
    return "hello world";
}

Calling MyAsyncMethod() without awaiting it causes a "Because this call is not awaited, the current method continues to run before the call is completed" warning in visual studio. On the page for that warning it states:

You should consider suppressing the warning only if you're sure that you don't want to wait for the asynchronous call to complete and that the called method won't raise any exceptions.

I'm sure I don't want to wait for the call to complete; I don't need to or have the time to. But the call might raise exceptions.

I've stumbled into this problem a few times and I'm sure it's a common problem which must have a common solution.

How do I safely call an async method without awaiting the result?

Update:

For people suggesting that I just await the result, this is code that is responding to a web request on our web service (ASP.NET Web API). Awaiting in a UI context keeps the UI thread free, but awaiting in a web request call will wait for the Task to finish before responding to the request, thereby increasing response times with no reason.

Solution 1

If you want to get the exception "asynchronously", you could do:

  MyAsyncMethod().
    ContinueWith(t => Console.WriteLine(t.Exception),
        TaskContinuationOptions.OnlyOnFaulted);

This will allow you to deal with an exception on a thread other than the "main" thread. This means you don't have to "wait" for the call to MyAsyncMethod() from the thread that calls MyAsyncMethod; but, still allows you to do something with an exception--but only if an exception occurs.

Update:

technically, you could do something similar with await:

try
{
    await MyAsyncMethod().ConfigureAwait(false);
}
catch (Exception ex)
{
    Trace.WriteLine(ex);
}

...which would be useful if you needed to specifically use try/catch (or using) but I find the ContinueWith to be a little more explicit because you have to know what ConfigureAwait(false) means.

Solution 2

You should first consider making GetStringData an async method and have it await the task returned from MyAsyncMethod.

If you're absolutely sure that you don't need to handle exceptions from MyAsyncMethod or know when it completes, then you can do this:

public string GetStringData()
{
  var _ = MyAsyncMethod();
  return "hello world";
}

BTW, this is not a "common problem". It's very rare to want to execute some code and not care whether it completes and not care whether it completes successfully.

Update:

Since you're on ASP.NET and wanting to return early, you may find my blog post on the subject useful. However, ASP.NET was not designed for this, and there's no guarantee that your code will run after the response is returned. ASP.NET will do its best to let it run, but it can't guarantee it.

So, this is a fine solution for something simple like tossing an event into a log where it doesn't really matter if you lose a few here and there. It's not a good solution for any kind of business-critical operations. In those situations, you must adopt a more complex architecture, with a persistent way to save the operations (e.g., Azure Queues, MSMQ) and a separate background process (e.g., Azure Worker Role, Win32 Service) to process them.

Solution 3

The answer by Peter Ritchie was what I wanted, and Stephen Cleary's article about returning early in ASP.NET was very helpful.

As a more general problem however (not specific to an ASP.NET context) the following Console application demonstrates the usage and behavior of Peter's answer using Task.ContinueWith(...)

static void Main(string[] args)
{
  try
  {
    // output "hello world" as method returns early
    Console.WriteLine(GetStringData());
  }
  catch
  {
    // Exception is NOT caught here
  }
  Console.ReadLine();
}

public static string GetStringData()
{
  MyAsyncMethod().ContinueWith(OnMyAsyncMethodFailed, TaskContinuationOptions.OnlyOnFaulted);
  return "hello world";
}

public static async Task MyAsyncMethod()
{
  await Task.Run(() => { throw new Exception("thrown on background thread"); });
}

public static void OnMyAsyncMethodFailed(Task task)
{
  Exception ex = task.Exception;
  // Deal with exceptions here however you want
}

GetStringData() returns early without awaiting MyAsyncMethod() and exceptions thrown in MyAsyncMethod() are dealt with in OnMyAsyncMethodFailed(Task task) and not in the try/catch around GetStringData()

Solution 4

I end up with this solution :

public async Task MyAsyncMethod()
{
    // do some stuff async, don't return any data
}

public string GetStringData()
{
    // Run async, no warning, exception are catched
    RunAsync(MyAsyncMethod()); 
    return "hello world";
}

private void RunAsync(Task task)
{
    task.ContinueWith(t =>
    {
        ILog log = ServiceLocator.Current.GetInstance<ILog>();
        log.Error("Unexpected Error", t.Exception);

    }, TaskContinuationOptions.OnlyOnFaulted);
}

Solution 5

This is called fire and forget, and there is an extension for that.

Consumes a task and doesn't do anything with it. Useful for fire-and-forget calls to async methods within async methods.

Install nuget package.

Use:

MyAsyncMethod().Forget();

EDIT: There is another way I've been rather using lately:

_ = MyAsyncMethod();

View more solutions

Comments

[Yahya]

Why not just create a completion method and just ignore it there? Because if it is running on background thread. Then it won't stop your program from terminating anyway.

[Peter Ritchie]

If you don't want to wait for the result, the only option is to ignore/suppress the warning. If you do want to wait for the result/exception then MyAsyncMethod().Wait()

[Admin]

About your edit: that does not make sense to me. Say the response is sent to the client 1 sec after the request, and 2 secs later your async method throws an exception. What would you do with that exception? You cannot send it to the client, if your response is already sent. What else would you do with it?

[Admin]

@Romoku Fair enough. Assuming someone looks at the log, anyway. :)

[David Rubin]

A variation on the ASP.NET Web API scenario is a self-hosted Web API in a long-lived process (like, say, a Windows service), where a request creates a lengthy background task to do something expensive, but still wants to get a response quickly with an HTTP 202 (Accepted).

[Kyle Delaney]

Why not use Task.Run()?

[George Powell]

I think you might have misunderstood. I do care if it throws exceptions and fails, but I don't want to have to await the method before returning my data. Also see my edit about the context I'm working in if that makes any difference.

[Peter Ritchie]

async is a bit more than just "awaiting" a result. "await" implies that the lines following "await" are executed asynchronously on the same thread that invoked "await". This can be done without "await", of course, but you end up having a bunch of delegates and lose the sequential look-and-feel of the code (as well as the ability to use using and try/catch...

[Stephen Cleary]

@GeorgePowell: It's very dangerous to have code running in an ASP.NET context without an active request. I have a blog post that may help you out, but without knowing more of your problem I can't say whether I'd recommend that approach or not.

[Servy]

@PeterRitchie You can have a method that is functionally asynchronous, doesn't use the await keyword, and doesn't use the async keyword, but there is no point whatsoever in using the async keyword without also using await in the definition of that method.

[George Powell]

I've accepted this as the answer but also see my answer below and Stephen Cleary's point specific to doing this in ASP.NET

[Peter Ritchie]

@Servy yes, of course. I'm not sure why you'd think I implied something different.

[Servy]

@PeterRitchie From the statement: "async is a bit more than just "awaiting" a result." The async keyword (you implied it's the keyword by enclosing it in backticks) means nothing more than awaiting the result. It's asynchrony, as the general CS concepts, that means more than just awaiting a result.

[Peter Ritchie]

@Servy async creates a state machine that manages any awaits within the async method. If there are no awaits within the method it still creates that state machine--but the method is not asynchronous. And if the async method returns void, there's nothing to await. So, it's more than just awaiting a result.

[Servy]

@PeterRitchie Are you sure that the state machine is actually created when the method has no await calls in it? They already introduce the compiler warning, so they know when it's the case. I know if I were the compiler I wouldn't bother generating the state machine as you know it won't ever be leveraged.

[Peter Ritchie]

@Servy Yep (I've reflected it many times), that's why you get the CS1998 warning. You could do async Task Method() (and no awaits in Method) and then await Method(). Without the state machine, you couldn't await on Method. I supose future expansion, virtual method, extension, etc...

[Servy]

@PeterRitchie As long as the method returns a task you can await it. There is no need for the state machine, or the async keyword. All you'd need to do (and all that really happens in the end with a state machine in that special case) is that the method is run synchronously and then wrapped in a completed task. I suppose technically you don't just remove the state machine; you remove the state machine and then call Task.FromResult. I assumed you (and also the compiler writers) could add the addendum on your own.

[dumbledad]

Note that neither ContiuneWith nor ConfigureAwait seem to be available in WinRT

[Mark Avenius]

I turned this into an extension method on Task: public static class AsyncUtility { public static void PerformAsyncTaskWithoutAwait(this Task task, Action<Task> exceptionHandler) { var dummy = task.ContinueWith(t => exceptionHandler(t), TaskContinuationOptions.OnlyOnFaulted); } } Usage: MyAsyncMethod().PerformAsyncTaskWithoutAwait(t => log.ErrorFormat("An error occurred while calling MyAsyncMethod:\n{0}", t.Exception));

[ganders]

@StephenCleary I have a similar need. In my example, I have/need a batch processing engine to run in the cloud, I'll "ping" the end point to kick off batch processing, but I want to return immediately. Since pinging it gets it started, it can handle everything from there. If there are exceptions that are thrown, then they'd just be logged in my "BatchProcessLog/Error" tables...

[tymtam]

Remove Console.ReadLine(); and add a little sleep/delay in MyAsyncMethod and you'll never see the exception.

[Peter Ritchie]

downvoter. Comments? If there's something wrong in the answer, I'd love to know and/or fix.

[Bartosz]

Hey - I did not downvote, but... Can you explain your update? The call was not supposed to be awaited, so if you do it like that, then you do wait for the call, you just don't continue on the captured context...

[Peter Ritchie]

"wait" isn't the correct description in this context. The line after the ConfiguratAwait(false) doesn't execute until the task completes, but the current thread doesn't "wait" (i.e. block) for that, the next line is called asynchronously to the await invocation. Without the ConfigureAwait(false) that next line would be executed on the original web request context. With the ConfigurateAwait(false) it's executed in the same context as the async method (task), freeing the original context/thread to continue on...

[Thanasis Ioannidis]

The ContinueWith version is not the same as the try{ await }catch{} version. In the first version, everything after ContinueWith() will execute immediately. The initial task is fired and forgotten. In the second version, everything after the catch{} will execute only after the initial task is completed. The second version is equivalent to "await MyAsyncMethod().ContinueWith(t => Console.WriteLine(t.Exception), TaskContinuationOptions.OnlyOnFaulted).ConfigureAwait(fals);

[Brian]

In C#7, you can replace var _ = MyAsyncMethod(); with _ = MyAsyncMethod();. This still avoids warning CS4014, but it makes it a bit more explicit that you're not using the variable.

[Crouching Kitten]

I tried a test app with .ConfigureAwait(false); but it still suspends a loop. The only solution I found was to make the called method async void (so no await is required), which solution everyone considers bad. But I think it's the nicest solution for creating an independent task.

[Paolo Fulgoni]

It doesn't do anything, it's just a trick to remove the warning. See github.com/microsoft/vs-threading/blob/master/src/…

[jrap]

Confirmed that the comment from Thanasis Ioannidis is best to answer the OP question. @PeterRitchie, I strongly recommend updating your accepted answer to avoid this being buried in comments.

[Theodor Zoulias]

This is just an overly convoluted way of converting an asynchronous method to async void, so that the behavior is changed from fire-and-forget to fire-and-crash. You can achieve the same thing in a straightforward manner like this: async void OnErrorCrash(this Task task) => await task;

[The Muffin Man]

I think what OP means is that he doesn't want the client (HTTP Request) to wait on whether logging something to a database succeeds. If the logging fails, sure the application should still have full control over handling that exception, but we don't need the client to wait around for the handling of that. I think what that means is that work needs to be done on a background thread. Yeah.. sucks to reserve a thread to do an async task, but it needs to be done to handle potential exceptions.

[Mauricio Gracia Gutierrez]

Correction: It does a bunch of stuff to avoid reacting to the call that was made.

[maraaaaaaaa]

wouldn't MyAsyncMethod().Result just do the same thing?