async / await - khi nào trả lại một Nhiệm vụ so với void?

Theo kịch bản nào người ta sẽ muốn sử dụng

public async Task AsyncMethod(int num)

thay vì

public async void AsyncMethod(int num)

Kịch bản duy nhất mà tôi có thể nghĩ đến là nếu bạn cần nhiệm vụ để có thể theo dõi tiến trình của nó.

Ngoài ra, trong phương pháp sau, có phải là async và đang chờ các từ khóa không cần thiết không?

public static async void AsyncMethod2(int num)
{
    await Task.Factory.StartNew(() => Thread.Sleep(num));
}

1) Thông thường, bạn sẽ muốn trả lại a Task. Ngoại lệ chính phải là khi bạn cần có voidkiểu trả về (cho các sự kiện). Nếu không có lý do gì để không cho phép người gọi awaitthực hiện nhiệm vụ của bạn, tại sao lại không cho phép?

2) asynccác phương thức trả về voidlà đặc biệt ở một khía cạnh khác: chúng đại diện cho các hoạt động không đồng bộ cấp cao nhất và có các quy tắc bổ sung có hiệu lực khi tác vụ của bạn trả về một ngoại lệ. Cách dễ nhất là thể hiện sự khác biệt bằng một ví dụ:

static async void f()
{
    await h();
}

static async Task g()
{
    await h();
}

static async Task h()
{
    throw new NotImplementedException();
}

private void button1_Click(object sender, EventArgs e)
{
    f();
}

private void button2_Click(object sender, EventArgs e)
{
    g();
}

private void button3_Click(object sender, EventArgs e)
{
    GC.Collect();
}

fNgoại lệ luôn được "quan sát". Một ngoại lệ để lại một phương thức không đồng bộ cấp cao nhất được xử lý đơn giản như bất kỳ ngoại lệ chưa được xử lý nào khác. gNgoại lệ không bao giờ được quan sát. Khi trình thu gom rác đến để dọn dẹp tác vụ, nó thấy rằng tác vụ dẫn đến một ngoại lệ và không ai xử lý ngoại lệ đó. Khi điều đó xảy ra, TaskScheduler.UnobservedTaskExceptionxử lý chạy. Bạn không bao giờ nên để điều này xảy ra. Để sử dụng ví dụ của bạn,

public static async void AsyncMethod2(int num)
{
    await Task.Factory.StartNew(() => Thread.Sleep(num));
}

Có, sử dụng asyncvà awaitở đây, họ đảm bảo phương pháp của bạn vẫn hoạt động chính xác nếu ném ngoại lệ.

để biết thêm thông tin, hãy xem: http://msdn.microsoft.com/en-us/magazine/jj991977.aspx

Tôi đã xem qua bài viết rất hữu ích này về asyncvà voidđược viết bởi Jérôme Laban: https://jaylee.org/archive/2012/07/08/c-sharp-async-tips-and-tricks-part-2-async-void .html

Điểm mấu chốt là async+voidcó thể làm sập hệ thống và thường chỉ nên được sử dụng trên các trình xử lý sự kiện phía UI.

Lý do đằng sau điều này là Bối cảnh đồng bộ hóa được sử dụng bởi AsyncVoidMethodBuilder, không có trong ví dụ này. Khi không có Bối cảnh đồng bộ hóa xung quanh, bất kỳ ngoại lệ nào được xử lý bằng phần thân của phương thức void async sẽ được lưu lại trên ThreadPool. Mặc dù dường như không có nơi logic nào khác có thể ném loại ngoại lệ chưa được xử lý đó, nhưng hậu quả đáng tiếc là quá trình này đang bị chấm dứt, bởi vì các ngoại lệ chưa được xử lý trên ThreadPool chấm dứt hiệu quả quá trình kể từ .NET 2.0. Bạn có thể chặn tất cả ngoại lệ chưa được xử lý bằng cách sử dụng sự kiện AppDomain.UnhandledException, nhưng không có cách nào để khôi phục quy trình từ sự kiện này.

Khi viết trình xử lý sự kiện UI, các phương thức void async bằng cách nào đó không gây đau đớn vì các ngoại lệ được xử lý theo cách tương tự được tìm thấy trong các phương thức không đồng bộ; họ bị ném vào người điều phối. Có khả năng phục hồi từ các trường hợp ngoại lệ như vậy, với nhiều hơn là chính xác cho hầu hết các trường hợp. Tuy nhiên, bên ngoài các trình xử lý sự kiện UI, các phương thức void async bằng cách nào đó rất nguy hiểm khi sử dụng và có thể không dễ tìm thấy.

Tôi có ý tưởng rõ ràng từ tuyên bố này.

1. Các phương thức void Async có ngữ nghĩa xử lý lỗi khác nhau. Khi một ngoại lệ được đưa ra khỏi phương thức Tác vụ không đồng bộ hoặc Tác vụ không đồng bộ, ngoại lệ đó được ghi lại và đặt vào đối tượng Tác vụ. Với các phương thức void async, không có đối tượng Nhiệm vụ, do đó, bất kỳ trường hợp ngoại lệ nào được đưa ra khỏi phương thức void async sẽ được đưa ra trực tiếp trên SyncizationContext (SyncizationContext đại diện cho một vị trí "trong đó" mã có thể được thực thi khi phương thức void async đã bắt đầu

Các ngoại lệ từ một phương pháp không đồng bộ Async không thể bị bắt với

private async void ThrowExceptionAsync()
{
  throw new InvalidOperationException();
}
public void AsyncVoidExceptions_CannotBeCaughtByCatch()
{
  try
  {
    ThrowExceptionAsync();
  }
  catch (Exception)
  {
    // The exception is never caught here!
    throw;
  }
}

Có thể quan sát các ngoại lệ này bằng AppDomain.UnhandledException hoặc một sự kiện bắt tất cả tương tự cho các ứng dụng GUI / ASP.NET, nhưng sử dụng các sự kiện đó để xử lý ngoại lệ thông thường là một công thức cho tính không thể nhầm lẫn (nó làm hỏng ứng dụng).

2. Các phương thức void Async có ngữ nghĩa sáng tác khác nhau. Các phương thức Async trả về Nhiệm vụ hoặc Tác vụ có thể được soạn thảo dễ dàng bằng cách sử dụng await, Task.WhenAny, Task.When ALL, v.v. Các phương thức Async trả về void không cung cấp một cách dễ dàng để thông báo mã cuộc gọi mà họ đã hoàn thành. Thật dễ dàng để bắt đầu một số phương thức void async, nhưng không dễ để xác định khi nào chúng kết thúc. Các phương thức void Async sẽ thông báo cho SyncizationContext của chúng khi chúng bắt đầu và kết thúc, nhưng SyncizationContext tùy chỉnh là một giải pháp phức tạp cho mã ứng dụng thông thường.

3. Phương thức Async Void hữu ích khi sử dụng trình xử lý sự kiện đồng bộ vì chúng đưa ra các ngoại lệ của chúng trực tiếp trên SyncizationContext, tương tự như cách xử lý sự kiện đồng bộ hóa xử lý

Để biết thêm chi tiết, hãy kiểm tra liên kết này https://msdn.microsoft.com/en-us/magazine/jj991977.aspx

Vấn đề với việc gọi async void là bạn thậm chí không nhận lại được nhiệm vụ, bạn không có cách nào để biết khi nào nhiệm vụ của chức năng đã hoàn thành (xem https://bloss.msdn.microsoft.com/oldnewthing/20170720-00/ ? p = 96655 )

Dưới đây là ba cách để gọi hàm async:

async Task<T> SomethingAsync() { ... return t; }
async Task SomethingAsync() { ... }
async void SomethingAsync() { ... }

Trong tất cả các trường hợp, hàm được chuyển thành một chuỗi các tác vụ. Sự khác biệt là những gì hàm trả về.

Trong trường hợp đầu tiên, hàm trả về một tác vụ cuối cùng tạo ra t.

Trong trường hợp thứ hai, hàm trả về một tác vụ không có sản phẩm, nhưng bạn vẫn có thể chờ đợi để biết khi nào nó chạy đến khi hoàn thành.

Trường hợp thứ ba là trường hợp khó chịu. Trường hợp thứ ba giống như trường hợp thứ hai, ngoại trừ việc bạn thậm chí không nhận lại nhiệm vụ. Bạn không có cách nào để biết khi nào nhiệm vụ của chức năng đã hoàn thành.

Trường hợp khoảng trống async là "lửa và quên": Bạn bắt đầu chuỗi nhiệm vụ, nhưng bạn không quan tâm đến khi nào nó kết thúc. Khi hàm trả về, tất cả những gì bạn biết là mọi thứ cho đến khi chờ đợi đầu tiên đã được thực thi. Tất cả mọi thứ sau lần chờ đợi đầu tiên sẽ chạy ở một số điểm không xác định trong tương lai mà bạn không có quyền truy cập.

Tôi nghĩ bạn cũng có thể sử dụng async voidđể khởi động các hoạt động nền, miễn là bạn cẩn thận để bắt ngoại lệ. Suy nghĩ?

class Program {

    static bool isFinished = false;

    static void Main(string[] args) {

        // Kick off the background operation and don't care about when it completes
        BackgroundWork();

        Console.WriteLine("Press enter when you're ready to stop the background operation.");
        Console.ReadLine();
        isFinished = true;
    }

    // Using async void to kickoff a background operation that nobody wants to be notified about when it completes.
    static async void BackgroundWork() {
        // It's important to catch exceptions so we don't crash the appliation.
        try {
            // This operation will end after ten interations or when the app closes. Whichever happens first.
            for (var count = 1; count <= 10 && !isFinished; count++) {
                await Task.Delay(1000);
                Console.WriteLine($"{count} seconds of work elapsed.");
            }
            Console.WriteLine("Background operation came to an end.");
        } catch (Exception x) {
            Console.WriteLine("Caught exception:");
            Console.WriteLine(x.ToString());
        }
    }
}

Câu trả lời của tôi rất đơn giản, bạn không thể chờ đợi phương thức void

Error   CS4008  Cannot await 'void' TestAsync   e:\test\TestAsync\TestAsyncProgram.cs

Vì vậy, nếu phương thức không đồng bộ, tốt hơn là nên chờ đợi, bởi vì bạn có thể mất lợi thế không đồng bộ.

Theo tài liệu của Microsoft , KHÔNG BAO GIỜ nên sử dụngasync void

Không làm điều này: Ví dụ sau sử dụng async voidlàm cho yêu cầu HTTP hoàn thành khi đạt được sự chờ đợi đầu tiên:

• Đó là LUÔN là một thực tiễn xấu trong các ứng dụng ASP.NET Core.

• Truy cập httpResponse sau khi yêu cầu HTTP hoàn tất.

• Sự cố quá trình.