.NET Core Web API是否需在Main中添加AppDomain未处理异常捕获？

Great question—let’s unpack this because .NET Core/.NET 5+ Web APIs have some key differences from classic console apps when it comes to exception handling.

First, What Your Existing Exception Middleware Covers #

Your configured exception handling middleware (like UseExceptionHandler or UseDeveloperExceptionPage) already catches most exceptions that happen within the HTTP request pipeline:

• Exceptions thrown inside controller actions
• Exceptions from middleware components in the request pipeline
• Unhandled exceptions from services called during request processing

These are the most common exceptions your API will encounter during normal operation, and your middleware handles them cleanly (returning appropriate error responses, logging details, etc.).

What AppDomain.CurrentDomain.UnhandledException Catches #

This event is a low-level, last-resort handler for exceptions that escape all other error handling mechanisms—specifically those that occur outside the HTTP request pipeline. Examples include:

• Unhandled exceptions in background threads (e.g., a Timer callback, a manually spawned thread, or an unawaited async task that throws)
• Exceptions during app startup before the request pipeline is fully initialized (e.g., errors configuring services or setting up the host)
• Unhandled exceptions in IHostedService implementations that aren’t caught by the host’s built-in error handling

By default, when such an exception occurs, the .NET runtime will terminate the process. Adding this event handler lets you log critical details before the process exits, which is invaluable for debugging crashes that don’t show up in your request-level logs.

The Tradeoffs of Adding (or Not Adding) It #

If You Add It: #

• Pros:
  • You get visibility into rare, non-request-related crashes that would otherwise leave you with no debugging trail.
  • You can perform last-minute cleanup (e.g., closing database connections, flushing log buffers) before the process terminates.
• Cons:
  • It’s a global handler, so you need to make sure your logging/cleanup code here is robust (you don’t want this handler throwing its own exception!).
  • You can’t prevent the process from terminating once an unhandled exception reaches this level (this behavior changed from .NET Framework to .NET Core).

If You Don’t Add It: #

• Pros:
  • You avoid the overhead of maintaining an extra global handler (though this is minimal).
  • Request pipeline exceptions are still fully covered by your existing middleware—your API will behave normally for user requests.
• Cons:
  • Non-request-related crashes will terminate the process silently (or with only generic system-level logs), making it extremely hard to diagnose the root cause.
  • You lose the chance to perform critical cleanup or capture detailed error context before the app exits.

Final Recommendation #

If your Web API uses any background tasks, hosted services, or has complex startup logic, add this handler as a safety net. Even if you don’t have those today, adding it is a low-effort way to future-proof your app against unexpected crashes. Just make sure to focus on logging as much context as possible (exception details, stack trace, timestamp) rather than trying to "fix" the exception at this point.

A simple implementation might look like this:

AppDomain.CurrentDomain.UnhandledException += (sender, args) =>
{
    var exception = args.ExceptionObject as Exception;
    // Use your initialized logger here
    Console.WriteLine($"UNHANDLED EXCEPTION: {exception?.Message}\n{exception?.StackTrace}");
};

内容的提问来源于stack exchange，提问作者Tech with Thiru