blocks|key|176533|text|如果你不需要async+(也就是，你可以直接返回Task+)，那么就不要使用async。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|176534|在某些情况下，return+await很有用，比如您有两个异步操作要做：|176535|var+intermediate+=+await+FirstAsync();
return+await+SecondAwait(intermediate);|code-block|syntax|javascript|176536|有关async性能的更多信息，请参阅有关该主题的Stephen+Toub的MSDN+article和video。|176537|更新：我已经写了一个更详细的blog+post。|BOLD|176538|entityMap|0|LINK|mutability|MUTABLE|url|http://msdn.microsoft.com/en-us/magazine/hh456402.aspx|1|http://channel9.msdn.com/Events/Build/BUILD2011/TOOL-829T|2|http://blog.stephencleary.com/2016/12/eliding-async-await.html^0|6|5|O|4|12|5|0|7|C|0|0|2|5|11|C|0|1E|5|1|0|0|3|E|9|2|0^^$0|@$1|2|3|4|5|6|7|13|8|@$9|14|A|15|B|C]|$9|16|A|17|B|C]|$9|18|A|19|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|1A|8|@$9|1B|A|1C|B|C]]|D|@]|E|$]]|$1|H|3|I|5|J|7|1D|8|@]|D|@]|E|$K|L]]|$1|M|3|N|5|6|7|1E|8|@$9|1F|A|1G|B|C]]|D|@$9|1H|A|1I|1|1J]|$9|1K|A|1L|1|1M]]|E|$]]|$1|O|3|P|5|6|7|1N|8|@$9|1O|A|1P|B|Q]]|D|@$9|1Q|A|1R|1|1S]]|E|$]]|$1|R|3|-4|5|6|7|1T|8|@]|D|@]|E|$]]]|S|$T|$5|U|V|W|E|$X|Y]]|Z|$5|U|V|W|E|$X|10]]|11|$5|U|V|W|E|$X|12]]]]

If you don't need <code>async</code> (i.e., you can return the <code>Task</code> directly), then don't use <code>async</code>.

There are some situations where <code>return await</code> is useful, like if you have two asynchronous operations to do:

<pre><code>var intermediate = await FirstAsync();
return await SecondAwait(intermediate);
</code></pre>

For more on <code>async</code> performance, see Stephen Toub's <a href="http://msdn.microsoft.com/en-us/magazine/hh456402.aspx" rel="noreferrer">MSDN article</a> and <a href="http://channel9.msdn.com/Events/Build/BUILD2011/TOOL-829T" rel="noreferrer">video</a> on the topic.

Update: I've written a <a href="http://blog.stephencleary.com/2016/12/eliding-async-await.html" rel="noreferrer">blog post</a> that goes into much more detail.

blocks|key|2991958|text|你想这样做的唯一原因是如果在前面的代码中有一些其他的await，或者如果你在返回结果之前以某种方式操作它。另一种可能发生这种情况的方式是通过改变异常处理方式的try/catch。如果你没有做任何这样的事情，那么你是对的，没有理由增加使方法成为async的开销。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2991959|entityMap^0|Q|5|27|9|3D|5|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]|$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|O|8|@]|D|@]|E|$]]]|G|$]]

The only reason you'd want to do it is if there is some other <code>await</code> in the earlier code, or if you're in some way manipulating the result before returning it. Another way in which that might be happening is through a <code>try/catch</code> that changes how exceptions are handled. If you aren't doing any of that then you're right, there's no reason to add the overhead of making the method <code>async</code>.

blocks|key|2992012|text|当普通方法中的return和async方法中的return+await表现不同时，有一种不为人知的情况:当与using+(或者，更一般地，与try块中的任何return+await+)结合使用时。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2992013|考虑以下两个版本的方法：|2992014|Task<SomeResult>+DoSomethingAsync()
{
++++using+(var+foo+=+new+Foo())
++++{
++++++++return+foo.DoAnotherThingAsync();
++++}
}

async+Task<SomeResult>+DoSomethingAsync()
{
++++using+(var+foo+=+new+Foo())
++++{
++++++++return+await+foo.DoAnotherThingAsync();
++++}
}|code-block|syntax|javascript|2992015|第一个方法将在Dispose()方法返回后立即对Foo对象执行DoAnotherThingAsync()操作，这很可能是在它实际完成之前很久的事情。这意味着第一个版本可能有buggy+(因为Foo处理得太快了)，而第二个版本可以很好地工作。|2992016|entityMap^0|7|6|E|5|N|C|1I|5|1Y|3|26|C|0|0|0|7|9|O|3|V|L|2N|3|0^^$0|@$1|2|3|4|5|6|7|Q|8|@$9|R|A|S|B|C]|$9|T|A|U|B|C]|$9|V|A|W|B|C]|$9|X|A|Y|B|C]|$9|Z|A|10|B|C]|$9|11|A|12|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|13|8|@]|D|@]|E|$]]|$1|H|3|I|5|J|7|14|8|@]|D|@]|E|$K|L]]|$1|M|3|N|5|6|7|15|8|@$9|16|A|17|B|C]|$9|18|A|19|B|C]|$9|1A|A|1B|B|C]|$9|1C|A|1D|B|C]]|D|@]|E|$]]|$1|O|3|-4|5|6|7|1E|8|@]|D|@]|E|$]]]|P|$]]

There is one sneaky case when <code>return</code> in normal method and <code>return await</code> in <code>async</code> method behave differently: when combined with <code>using</code> (or, more generally, any <code>return await</code> in a <code>try</code> block).

Consider these two versions of a method:

<pre><code>Task&lt;SomeResult&gt; DoSomethingAsync()
{
 using (var foo = new Foo())
 {
 return foo.DoAnotherThingAsync();
 }
}

async Task&lt;SomeResult&gt; DoSomethingAsync()
{
 using (var foo = new Foo())
 {
 return await foo.DoAnotherThingAsync();
 }
}
</code></pre>

The first method will <code>Dispose()</code> the <code>Foo</code> object as soon as the <code>DoAnotherThingAsync()</code> method returns, which is likely long before it actually completes. This means the first version is probably buggy (because <code>Foo</code> is disposed too soon), while the second version will work fine.

blocks|key|2992056|text|您可能需要等待结果的另一种情况是：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2992057|async+Task<IFoo>+GetIFooAsync()
{
++++return+await+GetFooAsync();
}

async+Task<Foo>+GetFooAsync()
{
++++var+foo+=+await+CreateFooAsync();
++++await+foo.InitializeAsync();
++++return+foo;
}|code-block|syntax|javascript|2992058|在这种情况下，GetIFooAsync()必须等待GetFooAsync的结果，因为两种方法的T类型不同，并且Task<Foo>不能直接赋值给Task<IFoo>。但是如果你等待结果，它就变成了可以直接赋值给IFoo的Foo。然后，异步方法只是将结果重新打包到Task<IFoo>中，然后就可以了。|offset|length|style|CODE|2992059|entityMap^0|0|0|7|E|P|B|1B|1|1J|9|1Z|A|2W|4|31|3|3M|A|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Q|8|@$I|R|J|S|K|L]|$I|T|J|U|K|L]|$I|V|J|W|K|L]|$I|X|J|Y|K|L]|$I|Z|J|10|K|L]|$I|11|J|12|K|L]|$I|13|J|14|K|L]|$I|15|J|16|K|L]]|9|@]|A|$]]|$1|M|3|-4|5|6|7|17|8|@]|9|@]|A|$]]]|N|$]]

Another case you may need to await the result is this one:

<pre><code>async Task&lt;IFoo&gt; GetIFooAsync()
{
 return await GetFooAsync();
}

async Task&lt;Foo&gt; GetFooAsync()
{
 var foo = await CreateFooAsync();
 await foo.InitializeAsync();
 return foo;
}
</code></pre>

In this case, <code>GetIFooAsync()</code> must await the result of <code>GetFooAsync</code> because the type of <code>T</code> is different between the two methods and <code>Task&lt;Foo&gt;</code> is not directly assignable to <code>Task&lt;IFoo&gt;</code>. But if you await the result, it just becomes <code>Foo</code> which is directly assignable to <code>IFoo</code>. Then the async method just repackages the result inside <code>Task&lt;IFoo&gt;</code> and away you go.

blocks|key|2779475|text|让原本简单的"thunk“方法异步在内存中创建一个异步状态机，而非异步方法则不会。虽然这通常可以让人们使用非异步版本，因为它更有效(这是真的)，这也意味着在发生挂起的情况下，您没有证据表明该方法涉及到”返回/继续堆栈“，这有时会使理解挂起变得更加困难。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2779476|所以，是的，当性能不是关键的时候(通常也不是)，我会在所有这些thunk方法上抛出异步，这样我就有了异步状态机来帮助我在以后诊断挂起，并帮助确保如果这些thunk方法随着时间的推移而发展，它们肯定会返回出错的任务，而不是抛出。|2779477|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Making the otherwise simple "thunk" method async creates an async state machine in memory whereas the non-async one doesn't. While that can often point folks at using the non-async version because it's more efficient (which is true) it also means that in the event of a hang, you have no evidence that that method is involved in the "return/continuation stack" which sometimes makes it more difficult to understand the hang. 

So yes, when perf isn't critical (and it usually isn't) I'll throw async on all these thunk methods so that I have the async state machine to help me diagnose hangs later, and also to help ensure that if those thunk methods ever evolve over time, they'll be sure to return faulted tasks instead of throw.

blocks|key|175076|text|这也让我感到困惑，我觉得之前的答案忽略了你的实际问题：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|175077|当您可以直接从内部DoAnotherThingAsync()调用返回|175078|时，为什么要使用return+await结构呢？|blockquote|175079|175080|175081|嗯，有时候你实际上想要一个Task<SomeType>，但大多数时候你实际上想要一个SomeType的实例，也就是任务的结果。|offset|length|style|CODE|175082|从你的代码中：|175083|async+Task<SomeResult>+DoSomethingAsync()
{
++++using+(var+foo+=+new+Foo())
++++{
++++++++return+await+foo.DoAnotherThingAsync();
++++}
}|code-block|syntax|javascript|175084|不熟悉语法的人(比如我)可能认为这个方法应该返回一个Task<SomeResult>，但是由于它被标记为async，这意味着它的实际返回类型是SomeResult。如果你仅仅使用return+foo.DoAnotherThingAsync()，你将返回一个无法编译的任务。正确的方法是返回任务的结果，因此return+await。|175085|entityMap^0|0|0|0|0|0|D|E|16|8|0|0|0|Q|G|1G|5|1Z|A|2H|W|48|C|0^^$0|@$1|2|3|4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|10|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|11|8|@]|9|@]|A|$]]|$1|G|3|-4|5|6|7|12|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|13|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|14|8|@$K|15|L|16|M|N]|$K|17|L|18|M|N]]|9|@]|A|$]]|$1|O|3|P|5|6|7|19|8|@]|9|@]|A|$]]|$1|Q|3|R|5|S|7|1A|8|@]|9|@]|A|$T|U]]|$1|V|3|W|5|6|7|1B|8|@$K|1C|L|1D|M|N]|$K|1E|L|1F|M|N]|$K|1G|L|1H|M|N]|$K|1I|L|1J|M|N]|$K|1K|L|1L|M|N]]|9|@]|A|$]]|$1|X|3|-4|5|6|7|1M|8|@]|9|@]|A|$]]]|Y|$]]

This also confuses me and I feel that the previous answers overlooked your actual question:

<blockquote>
 Why use return await construct when you can directly return Task from the inner DoAnotherThingAsync() invocation?
</blockquote>

Well sometimes you actually want a <code>Task&lt;SomeType&gt;</code>, but most time you actually want an instance of <code>SomeType</code>, that is, the result from the task.

From your code:

<pre><code>async Task&lt;SomeResult&gt; DoSomethingAsync()
{
 using (var foo = new Foo())
 {
 return await foo.DoAnotherThingAsync();
 }
}
</code></pre>

A person unfamiliar with the syntax (me, for example) might think that this method should return a <code>Task&lt;SomeResult&gt;</code>, but since it is marked with <code>async</code>, it means that its actual return type is <code>SomeResult</code>.
If you just use <code>return foo.DoAnotherThingAsync()</code>, you'd be returning a Task, which wouldn't compile. The correct way is to return the result of the task, so the <code>return await</code>.

blocks|key|173002|text|如果不使用return+await，那么在调试时或在日志中打印异常时，可能会破坏堆栈跟踪。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|173003|当您返回任务时，该方法就达到了它的目的，并且它不在调用堆栈之外。当您使用return+await时，您将把它留在调用堆栈中。|offset|length|style|CODE|173004|例如：|173005|使用await时的调用堆栈:A等待来自B的任务=>+B等待来自C的任务|173006|等待时调用堆栈使用：A等待来自C的任务，B已返回该任务。|BOLD|173007|entityMap^0|0|10|C|0|0|0|9|J|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@$D|S|E|T|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|U|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|V|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|W|8|@$D|X|E|Y|F|N]]|9|@]|A|$]]|$1|O|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|P|$]]

If you won't use return await you could ruin your stack trace while debugging or when it's printed in the logs on exceptions.

When you return the task, the method fulfilled its purpose and it's out of the call stack.
When you use <code>return await</code> you're leaving it in the call stack.

For example:

Call stack when using await:
A awaiting the task from B => B awaiting the task from C

Call stack when not using await:
A awaiting the task from C, which B has returned.

Is there any scenario where writing method like this:

<pre><code>public async Task&lt;SomeResult&gt; DoSomethingAsync()
{
 // Some synchronous code might or might not be here... //
 return await DoAnotherThingAsync();
}
</code></pre>

instead of this:

<pre><code>public Task&lt;SomeResult&gt; DoSomethingAsync()
{
 // Some synchronous code might or might not be here... //
 return DoAnotherThingAsync();
}
</code></pre>

would make sense?

Why use <code>return await</code> construct when you can directly return <code>Task&lt;T&gt;</code> from the inner <code>DoAnotherThingAsync()</code> invocation?

I see code with <code>return await</code> in so many places, I think I might have missed something. But as far as I understand, not using async/await keywords in this case and directly returning the Task would be functionally equivalent. Why add additional overhead of additional <code>await</code> layer?

What is the purpose of "return await" in C#?

有没有像这样写方法的场景：public async Task<SomeResult> DoSomethingAsync(){ // Some synchronous code might or might not be here... // return await DoAnotherThingAsync(...

问在C#中“返回等待”的目的是什么？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在C#中“返回等待”的目的是什么？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在C#中“返回等待”的目的是什么？
EN