Có phải Task.Result giống như .GetAwaiter.GetResult () không?

Gần đây tôi đã đọc một số mã sử dụng nhiều phương thức async, nhưng đôi khi cần phải thực thi chúng một cách đồng bộ. Mã này:

Foo foo = GetFooAsync(...).GetAwaiter().GetResult();

Cái này có giống như

Foo foo = GetFooAsync(...).Result;

Khá nhiều. Một sự khác biệt nhỏ: nếu Taskthất bại, GetResult()sẽ chỉ ném ngoại lệ gây ra trực tiếp, trong khi Task.Resultsẽ ném một AggregateException. Tuy nhiên, quan điểm của việc sử dụng một trong những điều đó là gìasync gì? Tùy chọn tốt hơn 100 lần là sử dụng await.

Ngoài ra, bạn không có ý định sử dụng GetResult(). Nó chỉ dành cho trình biên dịch, không dành cho bạn. Nhưng nếu bạn không muốn gây phiền nhiễu AggregateException, hãy sử dụng nó.

Task.GetAwaiter().GetResult()được ưa thích hơn Task.Waitvà Task.Resultbởi vì nó truyền bá các ngoại lệ thay vì gói chúng trong một AggregateException. Tuy nhiên, cả ba phương pháp này đều gây ra khả năng gây ra sự cố chết đói và luồng xử lý. Tất cả chúng nên được tránh để ủng hộasync/await .

Câu trích dẫn dưới đây giải thích tại sao Task.Wait và Task.Resultkhông chỉ đơn giản chứa hành vi lan truyền ngoại lệ của Task.GetAwaiter().GetResult()(do "thanh tương thích rất cao").

Như tôi đã đề cập trước đây, chúng tôi có một thanh tương thích rất cao và do đó chúng tôi đã tránh phá vỡ các thay đổi. Như vậy,Task.Wait giữ lại hành vi ban đầu của nó luôn luôn gói. Tuy nhiên, bạn có thể thấy mình trong một số tình huống nâng cao khi bạn muốn hành vi tương tự như chặn đồng bộ được sử dụng bởi Task.Wait, nhưng ở đó bạn muốn ngoại lệ ban đầu được truyền bá không được bao bọc thay vì được đặt trong một AggregateException. Để đạt được điều đó, bạn có thể nhắm mục tiêu trực tiếp đến người phục vụ của Nhiệm vụ. Khi bạn viết NỀN await task;, trình biên dịch sẽ dịch nó thành cách sử dụng Task.GetAwaiter()phương thức, nó trả về một thể hiện có GetResult()phương thức. Khi được sử dụng trên một Nhiệm vụ bị lỗi, GetResult()sẽ truyền bá ngoại lệ ban đầu (đây là cách mà Nghi phạmawait task; Martin Tấn có hành vi của nó). Do đó, bạn có thể sử dụngtask.GetAwaiter().GetResult()Nếu bạn muốn trực tiếp gọi logic truyền bá này.

https://bloss.msdn.microsoft.com/pfxteam/2011/09/11/task-exception-handling-in-net-4-5/

“ GetResult” Thực sự có nghĩa là “kiểm tra các nhiệm vụ cho các lỗi”

Nói chung, tôi cố gắng hết sức để tránh chặn đồng bộ trên một tác vụ không đồng bộ. Tuy nhiên, có một số tình huống tôi vi phạm nguyên tắc đó. Trong những điều kiện hiếm hoi đó, phương pháp ưa thích của tôi là GetAwaiter().GetResult()vì nó bảo tồn các ngoại lệ của nhiệm vụ thay vì gói chúng trong mộtAggregateException .

http://blog.stephencleary.com/2014/12/a-tour-of-task-part-6-results.html

https://github.com/aspnet/Security/issues/59

"Một lưu ý cuối cùng: bạn nên tránh sử dụng Task.Resultvà Task.Waitcàng nhiều càng tốt vì chúng luôn gói gọn ngoại lệ bên trong trong AggregateExceptionvà thay thế tin nhắn bằng một lỗi chung (Một hoặc nhiều lỗi xảy ra), khiến việc gỡ lỗi khó hơn. Ngay cả khi phiên bản đồng bộ không nên Không được sử dụng thường xuyên, bạn nên cân nhắc sử dụng Task.GetAwaiter().GetResult()thay thế. "

Một sự khác biệt nữa là khi asynchàm trả về Taskthay vì Task<T>sau đó bạn không thể sử dụng

GetFooAsync(...).Result;

Trong khi

GetFooAsync(...).GetAwaiter().GetResult();

vẫn hoạt động.

Tôi biết mã ví dụ trong câu hỏi là dành cho trường hợp Task<T>, tuy nhiên câu hỏi thường được hỏi.

Như đã đề cập nếu bạn có thể sử dụng await. Nếu bạn cần chạy mã đồng bộ như bạn đề cập .GetAwaiter().GetResult(), .Resulthoặc.Wait() có nguy cơ bị bế tắc như nhiều người đã nói trong các bình luận / câu trả lời. Vì hầu hết chúng ta thích oneliners, bạn có thể sử dụng chúng cho.Net 4.5<

Có được giá trị thông qua phương thức async:

var result = Task.Run(() => asyncGetValue()).Result;

Gọi đồng bộ một phương thức async

Task.Run(() => asyncMethod()).Wait();

Không có vấn đề bế tắc sẽ xảy ra do việc sử dụng Task.Run.

Nguồn:

https://stackoverflow.com/a/32429753/3850405

Nếu một tác vụ lỗi, ngoại lệ được ném lại khi mã tiếp tục gọi Waititer.GetResult (). Thay vì gọi GetResult, chúng ta chỉ cần truy cập vào thuộc tính Kết quả của tác vụ. Lợi ích của việc gọi GetResult là nếu tác vụ bị lỗi, ngoại lệ được ném trực tiếp mà không được bọc trong AggregateException, cho phép các khối bắt đơn giản và gọn gàng hơn.

Đối với các tác vụ không phổ biến, GetResult () có giá trị trả về void. Chức năng hữu ích của nó sau đó chỉ là để lấy lại ngoại lệ.

nguồn: c # 7.0 trong một Nutshell