在C#程序运行期间，当执行流遇到无法继续正常处理的错误状态时，CLR会构造一个异常对象并改变控制流，这种机制让开发者能将错误检测与错误处理解耦。异常不同于返回错误码，它具有自动沿调用栈向上传播的特性，直到被匹配的catch块捕获或者导致进程终止。理解异常在运行时的真实流转方式，是写出健壮代码的前提。
异常在CLR中的底层流转原理
当C#代码中使用throw语句或者公共语言运行时检测到如除零、空引用访问等故障时，系统会在托管堆上创建对应异常类型的实例，例如NullReferenceException或InvalidOperationException。此时当前方法的执行被中断，CLR开始执行栈展开（stack unwinding），依次检查调用栈上每个方法的异常处理表。这个表中记录了该方法用try-catch或try-finally保护的代码范围以及对应的捕获类型。
如果某个方法的catch块声明的类型与抛出的异常类型兼容，控制流就会跳转到该catch块，执行处理逻辑。若遍历完整个调用栈都没有找到匹配的处理器，则进程会被终止，并在调试环境下触发未处理异常事件。值得注意的是，finally块无论是否发生异常都会执行，它常用于释放文件句柄、数据库连接等非托管资源，这也是为什么用using语句包装实现了IDisposable的对象能防止资源泄漏。
异常的抛出成本相对较高，因为需要抓取调用栈信息并构造对象。在性能敏感的热点循环中，应当避免将异常用于控制正常业务流程，比如用异常来判断字符串能否转换为数字就远不如直接使用int.TryParse。下面代码展示了低效与高效的写法对比：
// 不推荐：用异常控制流程
int value;
try
{
value = int.Parse(userInput);
}
catch (FormatException)
{
value = 0;
}
// 推荐：使用TryParse避免异常开销
int safeValue;
if (!int.TryParse(userInput, out safeValue))
{
safeValue = 0;
}
开发中常见的异常处理误区
最普遍的误用是顶层统一使用catch (Exception ex)将全部异常吞掉，仅记录日志后继续运行。这种做法会让程序处于不确定状态，例如数据库事务已失败却继续处理后续业务，造成数据不一致。另一种极端是捕获了异常却不记录任何信息，使问题在测试环境无法复现，线上排查时毫无头绪。
还有开发者喜欢在底层库里捕获特定异常再抛出新的、更笼统的异常，却未保留原始异常引用。C#允许在throw新异常时通过构造函数传入innerException，若丢弃这一层，调用栈根源就丢失了。正确的做法类似throw new BusinessException("下单失败", ex);，这样上层既能识别业务错误，也能回溯技术原因。
部分人误以为async方法中异常会被自动处理，实际上未被await的Task若内部出错，异常会在垃圾回收时触发未观察任务异常。应使用await确保异常冒泡，或在Task上显式观察。以下示例说明了错误与正确等待的区别：
// 错误：未await，异常可能被忽略 Task.Run(() => DoWork()); // 正确：await让异常正常传播 await Task.Run(() => DoWork());
分层架构下的实战处理模式
在典型的三层应用中，数据访问层应抛出与基础设施相关的具体异常，如SqlException，但不应直接暴露给界面层。可以在服务层捕获后转换为领域异常，例如OrderNotFoundException，这样上层只关心业务语义。表现层则根据用户场景决定是显示友好提示还是跳转错误页。
对于可预见的用户输入错误，应在进入核心逻辑前用验证框架拦截，而不是依赖异常捕获。只有真正意外的故障才走异常通道。同时全局过滤器（如ASP.NET Core的UseExceptionHandler）适合做最后防线，记录未预期异常并返回标准错误结构，避免敏感堆栈信息泄露给客户端。
下面的代码展示了一个服务层转换异常的实践，既隔离了技术细节，又保留了排查线索：
public Order GetOrder(int id)
{
try
{
return _repository.Load(id);
}
catch (SqlException ex)
{
// 转换为领域异常并保留内部异常
throw new OrderQueryFailedException($"查询订单{id}失败", ex);
}
}
通过在各层明确异常职责，配合全局兜底与资源正确释放，C#应用才能在复杂业务下既稳定又不丢失诊断能力。异常不是敌人，错误使用才是风险源头。