捕获task.run异常的正确方式是在await该task时使用try-catch，因为await会自动解包task中封装的异常并重新抛出；2. 若在task.run内部使用try-catch但未重新throw，则异常不会传播到外部，导致外部无法感知错误，因此应避免在内部吞掉异常；3. 处理多个并行task时，使用task.whenall会聚合所有异常为aggregateexception，需遍历innerexceptions进行处理，而task.whenany可用于逐个处理任务完成状态，包括失败任务的异常；4. 异步异常传播机制是：异常被存储在task中使其状态变为faulted，await时自动解包aggregateexception并抛出原始异常，使其可在调用上下文中被捕获；5. async void方法抛出的异常无法被外部捕获，会导致应用程序崩溃，因此仅应用于事件处理程序，其他场景应使用async task。
在C#中，捕获
Task.Run产生的异常，核心思路是在
await该
Task的地方使用
try-catch块。因为
Task.Run返回的是一个
Task对象，异常会被封装在这个
Task内部，直到你
await它时才会被重新抛出。
解决方案
要捕获
Task.Run内部抛出的异常，最直接且推荐的方式是在调用
Task.Run并
await其结果的地方放置
try-catch。
await关键字会自动“解包”
Task中存储的异常，并将其作为普通的异常重新抛出，这样你就可以像处理同步代码一样捕获它。
using System;
using System.Threading.Tasks;
public class AsyncExceptionHandling
{
public static async Task RunExample()
{
Console.WriteLine("尝试运行一个会抛出异常的Task.Run...");
try
{
// Task.Run内部的代码
await Task.Run(() =>
{
Console.WriteLine("Task.Run内部开始执行...");
// 模拟一个耗时操作，然后抛出异常
Task.Delay(100).Wait(); // 同步等待，模拟工作
throw new InvalidOperationException("哎呀，Task.Run里面出错了！");
});
Console.WriteLine("Task.Run成功完成（如果能看到这行，说明没抛异常）");
}
catch (InvalidOperationException ex)
{
// 捕获到Task.Run内部抛出的异常
Console.WriteLine($"成功捕获到异常：{ex.Message}");
// 这里可以进行日志记录、错误处理等
}
catch (Exception ex)
{
// 捕获其他类型的异常
Console.WriteLine($"捕获到未知异常：{ex.Message}");
}
Console.WriteLine("\n尝试运行一个不会抛出异常的Task.Run...");
try
{
await Task.Run(() =>
{
Console.WriteLine("Task.Run内部执行成功，没有异常。");
Task.Delay(50).Wait();
});
Console.WriteLine("Task.Run成功完成。");
}
catch (Exception ex)
{
Console.WriteLine($"不应该捕获到异常，但捕获到了：{ex.Message}");
}
}
// 可以在主方法中调用
public static async Task Main(string[] args)
{
await RunExample();
Console.ReadKey();
}
}如果你的
Task.Run没有被
await，或者你直接访问了
Task.Result或
Task.Wait()，那么异常会被包装在
AggregateException中。
await的优势在于它会自动帮你解包这个
AggregateException，直接抛出其内部的第一个异常，让代码看起来更简洁。
为什么直接在Task.Run内部try-catch可能无效？
这其实是个常见的误解，或者说，是理解异常传播机制的一个关键点。如果你在
Task.Run的委托内部放置
try-catch，它确实能捕获到委托内部同步代码抛出的异常。然而，这只是在
Task内部处理了异常，这个异常并不会“消失”，而是被封装起来，成为这个
Task的“故障状态”。
举个例子：
public static async Task InternalTryCatchExample()
{
Console.WriteLine("尝试在Task.Run内部try-catch...");
try
{
await Task.Run(() =>
{
try
{
Console.WriteLine("Task.Run内部：准备抛出异常。");
throw new Exception("内部抛出的异常！");
}
catch (Exception ex)
{
Console.WriteLine($"Task.Run内部捕获到异常：{ex.Message}");
// 异常在这里被捕获了，但Task的状态仍然是Faulted
// 如果不重新抛出，Task外部将不会感知到这个异常
// throw; // 如果这里不重新抛出，外部的await就不会抛出异常
}
});
Console.WriteLine("外部await：Task.Run完成（如果内部没有重新抛出异常）。");
}
catch (Exception ex)
{
Console.WriteLine($"外部await：捕获到异常：{ex.Message}");
}
}在这个例子中，如果内部的
catch块没有
throw;，那么外部的
await就不会抛出异常，因为
Task的内部异常已经被处理了。但如果内部
catch块里有
throw;，那么异常会再次被封装到
Task中，并最终在
await时被外部
try-catch捕获。
所以，通常我们不建议在
Task.Run的委托内部进行业务逻辑的异常捕获，除非你确实想在
Task内部消化掉这个异常，不让它影响外部的流程。更标准的做法是让异常自然地传播出来，然后在
await的地方统一处理。这样可以保持业务逻辑和异常处理的分离，也更符合异步编程的异常传播模型。
处理多个并行Task的异常有哪些策略？
当我们需要同时运行多个异步操作，并希望统一处理它们的异常时，情况会稍微复杂一些，但C#的异步模型提供了强大的支持。
一种常见场景是使用
Task.WhenAll来等待所有任务完成。如果其中任何一个任务失败，
Task.WhenAll会抛出一个
AggregateException，这个异常会包含所有失败任务的异常。
public static async Task HandleMultipleTasks()
{
Console.WriteLine("\n处理多个并行Task的异常...");
var task1 = Task.Run(() =>
{
Task.Delay(200).Wait();
Console.WriteLine("Task 1 完成。");
return 1;
});
var task2 = Task.Run(() =>
{
Task.Delay(100).Wait();
Console.WriteLine("Task 2 失败！");
throw new InvalidOperationException("Task 2 抛出的异常");
});
var task3 = Task.Run(() =>
{
Task.Delay(300).Wait();
Console.WriteLine("Task 3 失败！");
throw new ArgumentException("Task 3 抛出的异常");
});
try
{
// Task.WhenAll 会等待所有任务完成，如果任何一个失败，它会抛出AggregateException
int[] results = await Task.WhenAll(task1, task2, task3);
Console.WriteLine($"所有任务成功完成，结果：{string.Join(", ", results)}");
}
catch (AggregateException ae)
{
Console.WriteLine("捕获到 AggregateException，包含多个子异常：");
foreach (var innerEx in ae.InnerExceptions)
{
Console.WriteLine($"- 内部异常类型: {innerEx.GetType().Name}, 消息: {innerEx.Message}");
// 这里可以根据异常类型进行不同的处理或日志记录
}
}
catch (Exception ex)
{
Console.WriteLine($"捕获到其他类型异常：{ex.Message}");
}
// 另一种情况是使用 Task.WhenAny，它会在任何一个任务完成时返回
Console.WriteLine("\n使用 Task.WhenAny 处理异常...");
var tasks = new List<Task> { task1, task2, task3 };
while (tasks.Count > 0)
{
var completedTask = await Task.WhenAny(tasks);
if (completedTask.IsFaulted)
{
// completedTask.Exception 是一个 AggregateException
Console.WriteLine($"Task.WhenAny: 发现一个失败的任务！");
foreach (var innerEx in completedTask.Exception.InnerExceptions)
{
Console.WriteLine($"- 失败任务的异常: {innerEx.Message}");
}
}
else if (completedTask.IsCompletedSuccessfully)
{
Console.WriteLine($"Task.WhenAny: 一个任务成功完成。");
}
else if (completedTask.IsCanceled)
{
Console.WriteLine($"Task.WhenAny: 一个任务被取消。");
}
tasks.Remove(completedTask); // 从列表中移除已完成的任务
}
}使用
Task.WhenAll时，你通常会捕获
AggregateException并遍历其
InnerExceptions集合。这对于需要所有任务都成功才能继续的场景非常有用。而
Task.WhenAny则适用于你只需要等待第一个完成的任务（无论成功、失败或取消），然后根据其状态进行后续处理的场景。
异步操作中异常传播的机制是怎样的？
异步操作中的异常传播，初看起来可能有点绕，但理解其核心机制对于编写健壮的异步代码至关重要。
当一个异步方法（或者
Task.Run内部的委托）抛出异常时，这个异常并不会立即中断当前的执行流，而是会被捕获并存储在它所属的
Task对象中。这个
Task的状态会变为
Faulted（故障）。
关键点在于
await关键字。当你
await一个
Task时，如果这个
Task处于
Faulted状态，
await会做两件事：
-
解包
AggregateException
：如果Task
内部存储的是一个AggregateException
（通常是多个异常或在某些特定情况下），await
会智能地解包它，并重新抛出其第一个内部异常。这意味着你通常可以直接catch
到原始的异常类型，而不是总要处理AggregateException
。这大大简化了异常处理的代码。 -
在调用者的上下文重新抛出：异常会在
await
所在的SynchronizationContext
（如果存在，比如UI线程）或线程池上下文（如果没有特定的SynchronizationContext
，比如控制台应用）重新抛出。这使得你可以像处理同步代码一样，在await
表达式外部的try-catch
块中捕获它。
如果一个
Task被创建了，但从未被
await，也没有通过
Wait()或
Result属性访问，那么它内部的异常在.NET Framework早期版本可能会导致
AppDomain.CurrentDomain.UnhandledException事件触发，或在某些情况下被
TaskScheduler.UnobservedTaskException事件捕获。但在现代的.NET版本和异步编程实践中，特别是当异步方法被正确地
await链式调用时，这种情况变得非常罕见。编译器和运行时会尽量确保所有
Task都被观察到。
一个值得注意的例外是
async void方法。
async void方法主要用于事件处理程序，它们没有返回
Task，因此无法被
await。这意味着从
async void方法中抛出的任何未捕获异常都会直接传播到当前的
SynchronizationContext，如果是在UI线程，通常会导致应用程序崩溃，因为没有
Task对象来捕获和存储这些异常。因此，除了事件处理程序，我们通常应避免使用
async void。
总结来说，异步异常传播的核心是：异常被封装在
Task中，
await负责解包并重新抛出，从而允许在调用链的更高层级进行统一的
try-catch处理。理解这一点，就能更自信地编写健壮的异步代码。
