应该方法获取任务并传递它等待它

本文关键字：等待 任务 方法 获取 | 更新日期: 2023-09-27 18:04:04

我有以下两个方法

public async Task<bool> DoSomething(CancellationToken.token) 
{
    //do something async
}
//overload with None token 
public /*async*/ Task<bool> DoSomething()
{
    return /*await*/ DoSomething(CancellationToken.None);
}

第二个方法是否应该用async/await关键字标记?

应该方法获取任务并传递它等待它

不需要这样做——如果你在第二个方法中使用await/async，你将增加额外的开销，在这种情况下，这将一无所获。

DoSomething(CancellationToken)内部的异步工作已经为您提供了适当的异步处理和封送回现有上下文。

在一天结束时，async和await实际上只是语言特性，使创建和组成Task变得容易。如果您已经有一个完美的Task返回，没有必要使用额外的语言支持来展开和重新包装成一个新的Task。

为Reed的好答案锦上添花，你可以这样想:

Func<int, int> GetFunc()
{
    Func<int, int> f = GetFunc(someParameter);

你应该说

    return f;

或者理由是"我应该在这里返回一个函数，所以让我们创建一个lambda来调用我手头的函数":

    return (int i) => f(i);

我希望你会做前者;你已经有一个Func<int, int>在手，所以只是返回它。不要创建调用另一个函数的函数。

如果你有

IEnumerable<int> GetSequence()
{
    IEnumerable<int> sequence = GetSequence(someParameter);

你会说

    return sequence;

或

    foreach(int item in sequence) yield return item;

?同样，我希望你会选择前者。你已经有了一个序列，那么为什么要费那么大的力气去创建一个枚举旧序列的新序列呢?

任务也是如此;就像你可以制作一个委托去包装另一个委托和一个序列去包装另一个序列，你可以制作一个任务去包装另一个任务，但你为什么要这样做呢?这是在浪费资源。

相关文章：