.NET 6中使用WaitAsync替代Task.WhenAny超时实现的差异问询

Great question! Let's break down the important differences between these two approaches that you might have missed:

• Exception Propagation for the Original Task
  Your original Task.WhenAny code doesn't automatically propagate exceptions from the sending task. Even if sending fails with an exception, await Task.WhenAny will just return the failed task, and your code will cancel the delay but won't throw the exception unless you explicitly await sending or await resultTask afterward.

  In contrast, await sending.WaitAsync(...) behaves exactly like directly awaiting sending—if sending throws an exception, it will be propagated immediately to your try block, which you'll need to handle (either with an additional catch clause or let it bubble up).

• Automatic vs. Manual Delay Task Cleanup
  Your original code uses a CancellationTokenSource wrapped in a using block to explicitly cancel the Task.Delay once sending completes. This ensures the delay task doesn't linger unnecessarily.

  The WaitAsync method handles this cleanup automatically under the hood: it creates an internal cancellation mechanism that cancels the timeout delay as soon as the original task completes, so you don't need to manage a CancellationTokenSource yourself. This makes the WaitAsync version more concise and less error-prone.

• Timeout Trigger Behavior
  In the original code, when the timeout hits, you immediately call _webSocket.Abort() without throwing a TimeoutException. The WaitAsync approach, however, throws a TimeoutException that you have to catch to trigger the abort. This is a behavioral difference in how you signal a timeout condition—one uses explicit branching, the other uses exception handling.

• Potential for Unobserved Exceptions (Edge Case)
  If you forget to await the sending task after the Task.WhenAny check in your original code, any exception from sending could become an unobserved exception (though in modern .NET, unobserved exceptions are logged rather than crashing the process). With WaitAsync, since you're directly awaiting the combined operation, exceptions from sending are always observed and propagated.

Overall, the WaitAsync version is more idiomatic for .NET 6+ and reduces boilerplate, but you need to account for the exception propagation difference—your original code silently ignores sending exceptions unless you add code to handle them, while WaitAsync will bubble them up immediately.

内容的提问来源于stack exchange，提问作者nop