.NET 4.5.2微服务管理器因异常意外传播导致退出问题排查

核心原因 #

你的问题根源在于**async void方法的异常处理机制**：在.NET 4.x中，async void方法抛出的异步异常不会被调用方的try/catch捕获，而是会直接冒泡到线程池的未处理异常处理器，最终触发进程终止。

之前测试场景正常，大概率是因为当时的异常发生在Run方法的同步执行阶段（比如反射加载、初始化等同步代码），这类异常能被OnTimer的try/catch捕获；而这次SQL连接异常是在GetNewEvents的异步操作回调阶段抛出，属于异步栈中的异常，无法被外层同步的try/catch捕获。

修复方案 #

1. 替换async void为async Task #

修改子服务的Run方法签名，从async void Run()改为async Task Run()，这是异步非UI场景的标准写法，能让异常被上层的try/catch捕获。

2. 调整调用方的异常捕获逻辑 #

如果你的定时任务使用的是System.Timers.Timer，需要将Elapsed事件处理方法改为异步包裹形式，确保能捕获Run方法的异步异常：

// 定时器触发事件
private async void Timer_Elapsed(object sender, ElapsedEventArgs e)
{
    try
    {
        // 调用子服务的Run方法并await，确保异常能被捕获
        await subService.Run();
    }
    catch (Exception ex)
    {
        // 记录异常日志，不会导致进程退出
        Logger.Error($"子服务执行异常: {ex.Message}", ex);
    }
}

3. 统一子服务接口规范 #

针对反射加载的子服务，定义一个标准接口强制返回Task，避免后续子服务再出现async void的写法：

public interface ISubService
{
    Task Run();
}

所有子服务实现该接口，反射加载时直接调用Run()并await即可。

额外说明 #

async void仅适用于WPF/WinForms等UI事件处理场景，在后台服务、定时任务等非UI场景中必须使用async Task，否则异步异常会绕过常规捕获逻辑，直接导致进程崩溃——这是.NET设计时的既定行为，和服务器是否更新无关。

内容的提问来源于stack exchange，提问作者P. Thatcher