如何优雅捕获ASP.NET Core 2定时器事件中的异常？

看起来你已经在使用ASP.NET Core 2.x里的BackgroundService实现后台仪表盘更新了，不过确实遇到了async void回调的异常处理问题，还有对更优周期性任务方案的疑问，我来帮你梳理下解决方案：

你提到的async void Timer回调确实是个坑——这种场景下抛出的异常会直接逃逸到线程池，无法被上层捕获，甚至可能导致应用崩溃。这里有两个更可控、易维护的方案：

1. 为单个更新任务单独捕获异常 #

首先建议你注入ILogger<GaugeUpdater>（记得在构造函数里添加依赖），然后在遍历_updatables时，对每个Update调用单独做异常处理。这样某个仪表盘更新失败不会影响其他实例，还能针对性记录日志或添加重试逻辑：

private readonly ILogger<GaugeUpdater> _logger;

// 构造函数注入ILogger
public GaugeUpdater(IEnumerable<IUpdateable> updateables, ILogger<GaugeUpdater> logger)
{
    _updatables = updateables.ToList();
    _logger = logger;
}

private async void UpdateAll(object state)
{
    foreach (var updatable in _updatables)
    {
        try
        {
            await updatable.Update();
        }
        catch (Exception ex)
        {
            // 记录异常，还可以扩展逻辑：标记实例状态、触发告警、重试等
            _logger.LogError(ex, "Failed to update updatable of type {UpdatableType}", updatable.GetType().FullName);
        }
    }
}

2. 彻底规避async void：用Task.Delay循环替代Timer #

如果你想完全避免async void的风险，可以把Timer逻辑替换成ExecuteAsync里的异步循环。这种方式更贴合BackgroundService的异步模型，异常处理更集中，还能避免Timer回调重叠的问题：

protected override async Task ExecuteAsync(CancellationToken stoppingToken)
{
    await InitializeUpdateables();

    const int intervalMilliseconds = 60_000;
    while (!stoppingToken.IsCancellationRequested)
    {
        try
        {
            // 批量执行所有更新（也可以改成逐个处理，灵活调整）
            var updateTasks = _updatables.Select(updatable => updatable.Update());
            await Task.WhenAll(updateTasks);
        }
        catch (Exception ex)
        {
            _logger.LogError(ex, "Batch dashboard update failed");
        }

        // 等待下一次执行，同时响应应用关闭的取消信号
        await Task.Delay(intervalMilliseconds, stoppingToken);
    }
}

这种方式的优势：

• 不会出现Timer回调重叠（如果某次更新耗时超过间隔，Timer会同时触发多个回调，而循环是完成一次再等下一次）
• 所有异常都能在循环内被捕获处理，不会逃逸到全局
• 天然支持优雅停止，响应stoppingToken

在ASP.NET Core 2.x里，BackgroundService（基于IHostedService）已经是官方推荐的后台任务实现方式，针对周期性任务，还有这些优化点：

• 优先用Task.Delay循环替代Timer：如上面的方案，它更适配异步编程模型，避免线程池线程的滥用和回调重叠问题
• 绑定应用生命周期：确保用services.AddHostedService<GaugeUpdater>()注册任务，这样应用启动时自动启动，关闭时会触发stoppingToken，让任务优雅停止
• 集成重试框架：如果需要对失败的更新进行重试，可以引入Polly库（ASP.NET Core 2.x支持集成），通过策略模式统一处理重试、熔断等逻辑，比手动写重试更易维护
• 控制并发数：如果更新任务是CPU密集型，建议用SemaphoreSlim限制并发，避免占用过多线程池资源影响主应用

AppDomain.UnhandledException确实是过于粗暴的全局捕获方案，它只能记录异常但无法阻止应用崩溃，而上面的方案都是在任务层面做精细化处理，更符合可维护和扩展的需求。

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