在C#开发中，Timer是实现周期性任务最常用的组件之一。当我们在Elapsed事件中编写业务代码时，一旦内部发生异常，很多开发者会发现程序既没有崩溃提示，也没有日志输出，任务却悄悄停止了。这种现象的根源在于System.Timers.Timer的设计机制：它运行在线程池线程上，事件委托中未处理的异常不会被传递到创建Timer的线程，而是被运行时悄然吞没。因此，掌握如何可靠地捕获Elapsed事件中的异常，是保证后台服务稳定性的关键。
System.Timers.Timer的异常吞没原理
System.Timers.Timer在触发Elapsed事件时，会通过线程池异步调用用户注册的处理方法。如果该方法内部抛出未捕获的异常，.NET运行时会认为这是后台线程上的未处理异常。在早期的.NET Framework版本中，这类异常可能导致进程终止；而在后续版本中，默认策略是忽略线程池线程上的未处理异常，仅将其记录到Application Domain的UnhandledException事件（如果未被订阅则直接丢弃）。这就造成了Elapsed事件“静默失败”的假象。
我们可以通过一个简单的示例来观察这个问题。下面的代码中，Elapsed事件故意除以零，但程序主线程完全感知不到错误：
using System;
using System.Timers;
class Program
{
static void Main()
{
Timer timer = new Timer(1000);
timer.Elapsed += (s, e) =>
{
int x = 0;
int y = 1 / x; // 抛出 DivideByZeroException
};
timer.Start();
Console.WriteLine("主线程继续运行，等待按键");
Console.ReadKey();
}
}
运行上述代码，控制台只会输出“主线程继续运行，等待按键”，除零异常不会显示。如果业务依赖该定时任务推送数据，那么任务中断后系统可能长时间处于不可用状态而无人察觉。因此，绝不能假定Elapsed事件中的代码永远安全。
在Elapsed事件内部使用try-catch捕获异常
最直接且推荐的方案是在Elapsed事件处理方法内部用try-catch块包裹所有逻辑。由于事件本身运行在线程池线程，只有在其执行栈内捕获异常，才能阻止异常向外传播并被运行时丢弃。在catch块中，我们可以进行日志记录、告警，甚至决定是否重启Timer。
下面的代码展示了标准的防御性写法。我们将可能出错的逻辑放入try块，在catch中写入本地日志，并通过一个标志位避免重叠执行：
using System;
using System.Timers;
using System.IO;
class SafeTimer
{
private static Timer _timer;
private static readonly object _lock = new object();
static void Main()
{
_timer = new Timer(2000);
_timer.Elapsed += OnElapsed;
_timer.AutoReset = true;
_timer.Start();
Console.ReadKey();
}
private static void OnElapsed(object sender, ElapsedEventArgs e)
{
try
{
// 模拟业务处理
string content = File.ReadAllText("config.txt");
int value = int.Parse(content);
Console.WriteLine("处理值：" + value);
}
catch (Exception ex)
{
// 捕获所有异常，记录到文件
File.AppendAllText("error.log",
DateTime.Now + " 定时任务异常：" + ex.Message + Environment.NewLine);
// 必要时可重启或停止
// _timer.Stop();
}
}
}
这种写法的优点是逻辑清晰、异常不漏。缺点是需要每个事件处理方法都写样板代码，如果团队中有多人开发，容易遗漏。为此可以封装一个通用的安全订阅方法，统一包裹try-catch并接入日志框架，降低人为疏忽风险。
另外要注意，Elapsed事件可能重入。若上一次执行尚未结束而新的周期已到，两个线程会同时进入处理方法。此时catch中的非线程安全操作（如直接写文件）也需要加锁，或使用并发队列由单独线程消费日志，避免日志内容错乱。
System.Threading.Timer的回调异常与全局兜底
除了System.Timers.Timer，另一种常见的是System.Threading.Timer，它使用TimerCallback委托。其回调同样运行在线程池上，异常也必须内部处理。不同的是，它没有Elapsed事件模型，而是直接传入回调方法，因此我们更应在回调入口处包好异常处理。
示例代码如下，展示如何在回调中捕获异常并通知主程序：
using System;
using System.Threading;
class ThreadingTimerDemo
{
static void Main()
{
using (Timer timer = new Timer(Callback, null, 0, 1000))
{
Console.ReadKey();
}
}
private static void Callback(object state)
{
try
{
throw new InvalidOperationException("模拟回调异常");
}
catch (Exception ex)
{
Console.WriteLine("捕获到Timer回调异常：" + ex.Message);
}
}
}
如果确实无法保证每个回调都写try-catch，还可以在应用程序启动时订阅AppDomain.CurrentDomain.UnhandledException，作为最后一道防线记录日志。但该事件触发时异常已脱离Timer控制，且可能导致进程退出，不宜作为常规捕获手段。更合理的架构是在定时任务框架层统一拦截，业务层只写纯逻辑，由框架负责异常转日志和任务续跑。
综合来看，C#中Timer的Elapsed或回调异常不会自动冒泡，必须在执行线程内捕获。根据项目规模选择内部try-catch或封装安全定时器，才能构建健壮的周期性任务系统。