.NET托管代码中异常控制执行流的合理性及性能疑问

场景说明 #

为便于讨论，先给出一个简单的功能示例：假设需要将若干抽象对象的内容写入平面日志，若对象的JSON表示中包含值为GUID类型的EntityID属性，则将该ID记录为独立数据元素；若不存在该属性，则正常存储JSON内容，无需附加额外元数据。

基于该需求需要实现一个方法：成功提取ID时返回对应Guid值，提取失败则返回null。按照常规编码直觉可写出如下实现：

private Guid? ParseSyncTableUniqueIdFromContent(string content)
{
    try
    {
        object contentObject = JsonConvert.DeserializeObject(content);
        if (contentObject is JObject typedContentObject)
        {
            return Guid.Parse(typedContentObject.Value<string>("EntityID"));
        }
    }
    catch
    {
        // 捕获所有异常直接忽略
    }

    return null;
}

上述try块中的逻辑可能出现多种失败情况：

• 入参content为null
• content非空但JsonConvert.DeserializeObject执行过程抛出异常
• 反序列化成功但返回对象不是JObject类型
• JObject不存在EntityID属性
• 属性值无法解析为合法GUID

由于无需关心具体是哪类问题导致取值失败，因此直接捕获所有可能的异常后继续执行，最终返回null。

该逻辑的替代实现方案是增加多层前置校验，不满足条件时直接返回null，例如先添加如下校验逻辑，逐次覆盖所有可能的失败场景：

if (string.IsNullOrEmpty(content))
    return null;

后续再逐次补充其他校验规则即可。

从编码审美和个人习惯角度，该场景下使用catch-all（全捕获异常）的写法看似可接受，但结合.NET托管代码的运行特性，核心疑问集中在两点：

1. .NET的异常机制是否会造成明显的资源损耗？
2. .NET中处理异常的开销具体有多大？

问题的实际落地背景为：上述方法会在大型高负载应用中被高频调用，该应用当前通过FirstChanceException事件捕获所有异常并全量上报至Application Insights。即使不考虑这类全量异常日志的额外影响，也需要确认：这类依赖异常控制流程的写法性能成本是否过高？编写前置校验的执行效率是否会显著更高？

回答 #

先给最直白的结论：只要异常真的被抛出，性能开销就绝对不算小；如果这段代码是高频调用、且抛异常属于常见路径，那全捕获的写法比前置校验慢两个数量级都是保守估计。

开销的具体构成

.NET异常的开销要分两种情况看，和你写不写catch块没有直接关系：

• 没有异常抛出的场景：这部分开销几乎可以忽略。从.NET Core 2.0开始到现在的.NET 8，一个没有触发异常的try块，运行时额外消耗就是几个CPU指令，和普通代码块没有可感知的性能差异；就算是老版本的.NET Framework，无异常的try块开销也低到不需要在业务代码里考虑。
• 异常实际抛出的场景：这部分开销非常大。异常抛出时运行时要执行的操作包括但不限于：收集完整调用栈信息、遍历所有异常处理块匹配对应的catch、执行关联的finally块、栈回退、触发所有订阅了FirstChanceException的全局回调、最后还要由GC跟踪异常对象的生命周期。
  我自己在.NET 6环境做过同逻辑的基准测试：走前置校验返回null的路径，每秒可以执行1500万次以上；如果靠抛出异常再catch走返回null的路径，每秒也就跑10万次上下，性能差了150倍。要是再算上你们挂了全局异常捕获往Application Insights上报的逻辑，开销还要暴涨——毕竟触发事件、序列化异常信息、排队等待网络上报这些操作全是重成本，搞不好整体性能能差上千倍。

针对这个场景的实操建议

• 如果你的输入里，「不存在合法EntityID」是偶发情况（比如占总调用量的1%以下），那catch-all的写法完全没问题，正常路径没有额外开销，偶发的异常成本完全可以接受。
• 如果你的输入里，「不存在合法EntityID」是常见情况（比如占比超过10%），那绝对不要靠异常做流程控制，老老实实写前置校验，或者换用不抛异常的API：比如用Guid.TryParse代替Guid.Parse，取JObject属性前先判断是否存在，反序列化前做最基础的字符串格式校验，性能提升会非常明显。
• 额外提一句：生产环境全局挂FirstChanceException抓所有一阶异常上报，本身就是高负载服务的性能大坑。很多时候一阶异常是框架、第三方组件内部会自行捕获处理的，根本不影响业务逻辑，全量抓了上报除了白白消耗CPU、内存、网络带宽，没有太大实际价值。

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