从Task.ContinueWith抛出异常到主线程

Question

In an ASP.NET Core Controller -> I'm trying to rethrow an exception from a Task (in order to log the exception), but I don't understand why it's not caught by the global controller exception filter.

public IActionResult MyAction()
{
    Task task = GetMyTask();

    SynchronizationContext.SetSynchronizationContext(new SynchronizationContext());

    task.ContinueWith(t =>
        {
            if (t.IsFaulted && t.Exception != null && t.Exception.InnerException != null)
            {
                throw t.Exception.InnerException; // Code reached, but this exception is NOT handled by the controller global error handler
            }
        }, cancellationToken: CancellationToken.None, continuationOptions: TaskContinuationOptions.OnlyOnFaulted, scheduler: TaskScheduler.FromCurrentSynchronizationContext() );

    throw new Exception("This exception is handled by the controller global error handler");
    return Ok();
}

I don't want to use await , since this task is run-and-forget.

Answer 1

The await keyword has pretty much one job: it holds the processing of the code until the task returns. It also unwraps the task, but just as a convenience.

Since you're not using await here, that means the calling code moves on and your response it returned while the task is still completing. You're essentially taking it out of the request pipeline context, which then means you cannot catch any exceptions it throws - it's fire and forget, emphasis on the forget .

This is not the same thing as doing something "in the background". If you're trying to handle some long-running process outside of the request, the solution to that is to schedule it and have processed by something like an IHostedService or a library like Hangfire. That way your request can go ahead an return, but you're now doing the work in a monitored context, where you can do things like throw exceptions. However, you need to be more careful at that point, because the exception still won't bubble up to your global exception handler, because there's no request in play. Instead, you'd need to catch the exception(s) and then notify the client via something like SignalR (websockets), log it, etc. This will also allow you to then potentially monitor the status of the process, and report back to the user (again via SignalR) both progress and completion. None of that is possible by just having a task run without awaiting it.