Blazor中为何需调度异常至同步上下文？示例疑问解析

微软Blazor文档指出，在未运行于同步上下文的任务中发生的异常，需被发回至同步上下文，才能应用错误边界等机制。这一点逻辑通顺，但文档给出如下示例：

<button @onclick="SendReport">Send report</button>

@code {
    private void SendReport()
    {
        _ = SendReportAsync();
    }

    private async Task SendReportAsync()
    {
        try
        {
            await ReportSender.SendAsync();
        }
        catch (Exception ex)
        {
            await DispatchExceptionAsync(ex);
        }
    }
}

但由于SendReportAsync由按钮点击触发，必然在Blazor同步上下文执行，且await ReportSender.SendAsync()未使用ConfigureAwait(false)，按理应确保await后的代码也在同步上下文运行。既然try块中所有代码都在Blazor同步上下文执行，为何还需用DispatchExceptionAsync调度异常？

核心原因解析 #

• 未被Blazor跟踪的Task异常：示例中SendReport是void类型的事件处理方法，调用SendReportAsync后直接丢弃了返回的Task（_ = ...）。Blazor的错误处理机制只会自动跟踪由它发起的异步操作——比如直接绑定async Task类型的事件处理方法时，Blazor会负责监听Task的状态并处理异常。而这种被手动丢弃的Task，哪怕异常发生在同步上下文内，Blazor也不会自动捕获处理。

• 同步阶段异常的特殊场景：如果ReportSender.SendAsync在进入异步逻辑前（同步执行阶段）就抛出异常，这个异常会直接在SendReport的调用栈中抛出，但因为SendReport是void且没有等待Task完成，该异常会成为未观察异常，无法被错误边界捕获。DispatchExceptionAsync的作用是将这类异常重新调度到Blazor的同步上下文，确保错误边界能感知并处理。

• 示例的通用性设计：文档的这个示例其实是为了覆盖更广泛的场景——比如SendReportAsync可能在某些情况下从非同步上下文触发（如后台线程），或者开发者习惯用void事件处理方法并丢弃Task。DispatchExceptionAsync可以统一异常处理逻辑，确保无论异常发生在同步阶段还是异步阶段、无论触发上下文是什么，都能被Blazor的错误机制正确处理。

如果把SendReport改成async Task类型的方法（而非void），Blazor会自动跟踪该Task的执行，此时即使不使用DispatchExceptionAsync，异常也能被错误边界捕获。

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