.NET Core 异常(Exception)底层原理浅谈
中断的基础知识
https://www.cnblogs.com/lmy5215006/p/18816120
用户异常
C#的异常，在Windows平台下是完全围绕SEH处理框架来展开。在Linux上则是围绕signal模拟成SEH结构，因为都会进入内核态，所以其开销并不低，内部走了很多流程。
static void Main(string[] args)
{
try
{
var num = Convert.ToInt32("a");
}
catch (Exception ex)
{
Debugger.Break();
Console.WriteLine(ex.Message);
}
Console.ReadLine();
}
眼见为实：用户Execption的调用栈
硬件异常
硬件异常指CPU执行机器码出现异常后，由CPU通知操作系统，操作系统再通知进程触发的异常。
比如：
- 内核模式切换：syscall
- 访问违例：AccessViolationException
- visual studio中F9中断：int 3
static void Main(string[] args)
{
try
{
string str = null;
var len = str.Length;
Console.WriteLine(len);
}
catch (Exception ex)
{
Debugger.Break();
Console.WriteLine(ex.ToString());
}
Console.ReadLine();
}
与用户异常不同的是，异常的发起点在CPU上，并且CLR为了统一处理。会先将硬件异常转换成用户异常。以此来复用后续逻辑。所以相比用户异常，硬件异常的开销更大
眼见为实：硬件Execption的调用栈
硬件异常如何与用户异常绑定?
上面说到，CLR会先将硬件异常转换成用户异常。那么在抛出异常的时候，如何正确抛出一个托管堆认识的异常呢？
以空指针异常为例
核心逻辑在ProcessCLRException中，它会判断 Thread 是否挂了异常？没有的话就会通过MapWin32FaultToCOMPlusException来转换，然后通过 pThread.SafeSetThrowables 塞入到线程里。从而实现了硬件异常在托管堆上的映射。
眼见为实
上源码
https://github.com/dotnet/runtime/blob/main/src/coreclr/vm/excep.cpp
.NET 异常处理流程
对.NET Runtime来说，主要实现以下四个操作
1. 捕获异常并抛出异常的位置
.NET9之前进入内核态利用SEH机制捕获并定位异常，.NET9之后在用户态的托管层自行捕获。
2. 通过线程栈空间获取异常调用栈
线程的栈空间维护了整个调用栈，扫描整个栈空间即可获取。
windbg的k系列命令就是参考此原理。
3. 获取元数据的异常处理表
一旦方法中有try-catch语句块时，JIT会将try-catch的适用范围记录下来，并整理成异常处理表(Execption Handling Table , EH Table)
C# 代码
public class ExceptionEmample
{
public static void Example()
{
try
{
Console.WriteLine("Try outer");
try
{
Console.WriteLine("Try inner");
}
catch (Exception)
{
Console.WriteLine("Catch Expception inner");
}
}
catch (ArgumentException)
{
Console.WriteLine("Catch ArgumentException outer");
}
catch (Exception)
{
Console.WriteLine("Catch Exception outer");
}
finally
{
Console.WriteLine("Finally outer");
}
}
}
IL代码
.method public hidebysig static void Example() cil managed
{
// Code size 96 (0x60)
.maxstack 1
IL_0000: nop
IL_0001: nop
IL_0002: ldstr "Try outer"
IL_0007: call void [System.Console]System.Console::WriteLine(string)
IL_000c: nop
IL_000d: nop
IL_000e: ldstr "Try inner"
IL_0013: call void [System.Console]System.Console::WriteLine(string)
IL_0018: nop
IL_0019: nop
IL_001a: leave.s IL_002c
IL_001c: pop
IL_001d: nop
IL_001e: ldstr "Catch Expception inner"
IL_0023: call void [System.Console]System.Console::WriteLine(string)
IL_0028: nop
IL_0029: nop
IL_002a: leave.s IL_002c
IL_002c: nop
IL_002d: leave.s IL_004f
IL_002f: pop
IL_0030: nop
IL_0031: ldstr "Catch ArgumentException outer"
IL_0036: call void [System.Console]System.Console::WriteLine(string)
IL_003b: nop
IL_003c: nop
IL_003d: leave.s IL_004f
IL_003f: pop
IL_0040: nop
IL_0041: ldstr "Catch Exception outer"
IL_0046: call void [System.Console]System.Console::WriteLine(string)
IL_004b: nop
IL_004c: nop
IL_004d: leave.s IL_004f
IL_004f: leave.s IL_005f
IL_0051: nop
IL_0052: ldstr "Finally outer"
IL_0057: call void [System.Console]System.Console::WriteLine(string)
IL_005c: nop
IL_005d: nop
IL_005e: endfinally
IL_005f: ret
IL_0060:
// Exception count 4
.try IL_000d to IL_001c catch [System.Runtime]System.Exception handler IL_001c to IL_002c
.try IL_0001 to IL_002f catch [System.Runtime]System.ArgumentException handler IL_002f to IL_003f
.try IL_0001 to IL_002f catch [System.Runtime]System.Exception handler IL_003f to IL_004f
.try IL_0001 to IL_0051 finally handler IL_0051 to IL_005f
} // end of method ExceptionEmample::Example
IL代码中最后4行就代表了方法的异常处理表。
1. IL_000d to IL_001c 之间代码发生的Exception异常由IL_001c to IL_002c 之间的代码处理
2. IL_0001 to IL_002f 之间发生的ArgumentException异常由IL_002f to IL_003f之间的代码处理
3. IL_0001 to IL_002f 之间发生的Exception异常由IL_003f to IL_004f之间的代码处理
4. IL_0001 to IL_0051 之间无论发生什么，结束后都要执行IL_0051 to IL_005f之间的代码
4. 枚举异常处理表，调用对应的catch块与finally块
当异常发生时，Runtime会枚举EH Table，找出并调用对应的catch块与finally块。
核心方法为ProcessManagedCallFrame：
https://github.com/dotnet/runtime/blob/main/src/coreclr/vm/exceptionhandling.cpp
需要注意的是，一旦CLR找到catch块，就会先执行内层所有finally块中的代码，再等到当前catch块中的代码执行完毕finally才会执行
5. 重新抛出异常
在执行catch,finally的过程中，如果又抛出了异常。程序会再次进入ProcessCLRException中走重复流程。
但是调用链会消失，如果想要防止调用链丢失，需要特殊处理。
static void Main(string[] args)
{
try
{
Test();
}
catch (Exception ex)
{
Console.WriteLine(ex);
}
}
private static void Test()
{
try
{
throw new Exception("test");
}
catch (Exception ex)
{
//throw ex; //会丢失调用链,找不到真正的异常所在
//throw; //调用链完整
//ExceptionDispatchInfo.Capture(ex).Throw();//调用链更完整，显示了重新抛出异常所在的位置。
}
}
我在这里踩过大坑，使用throw ex重新抛出异常，结果丢失了异常真正的触发点，日志跟没记一样。
finally一定会执行吗?
常规情况下，finally是保证会执行的代码，但如果直接用win32函数TerminateThread杀死线程，或使用System.Environment的Failfast杀死进程，finally块不会执行。
先执行return还是先执行finally?
C#代码
~~~
public static int Example2()
{
try
{
return 100+100;
}
finally
{
Console.WriteLine("finally");
}
}
~~~
IL代码
.method public hidebysig static int32 Example2() cil managed
{
// Code size 22 (0x16)
.maxstack 1
.locals init (int32 V_0)
IL_0000: nop
IL_0001: nop
IL_0002: ldc.i4.1 //将100+100的值，压入Evaluation Stack
IL_0003: stloc.0 //从Evaluation Stack出栈，保存到序号为0的本地变量
IL_0004: leave.s IL_0014 //退出代码保护区域，并跳转到指定内存区域IL_0014， 指令 leave.s 清空计算堆栈并确保执行相应的周围 finally 块。
IL_0006: nop
IL_0007: ldstr "finally"
IL_000c: call void [System.Console]System.Console::WriteLine(string)
IL_0011: nop
IL_0012: nop
IL_0013: endfinally
IL_0014: ldloc.0 //读取序号0的本地变量并存入Evaluation Stack
IL_0015: ret //从方法返回，返回值从Evaluation Stack中获取
IL_0016:
// Exception count 1
.try IL_0001 to IL_0006 finally handler IL_0006 to IL_0014
} // end of method ExceptionEmample::Example2
从IL中可以看到，当try中包含return语句时，编译器会生成一个临时变量将返回值保存起来。然后再执行finally块。最后再return 临时变量。这个过程称为局部展开(local unwind)
再举一个例子
C#代码
public static int Test()
{
int result = 1;
try
{
return result;
}
finally
{
result = 3;
}
}
IL代码
.method public hidebysig static int32 Test() cil managed
{
// 代码大小 15 (0xf)
.maxstack 1
.locals init (int32 V_0,
int32 V_1)
IL_0000: nop
IL_0001: ldc.i4.1 //将常量1压栈
IL_0002: stloc.0 //将序号0出栈，赋值给result
IL_0003: nop
IL_0004: ldloc.0 //将当前方法序号0的变量，也就是result,压入栈中。
IL_0005: stloc.1 //将序号1的值出栈，保存到一个临时变量中。也就是return的值
IL_0006: leave.s IL_000d //跳转到对应行, 指令 leave.s 清空计算堆栈并确保执行相应的周围 finally 块。
IL_0008: nop
IL_0009: ldc.i4.3
IL_000a: stloc.0
IL_000b: nop
IL_000c: endfinally
IL_000d: ldloc.1 //将return的值 入栈
IL_000e: ret //执行return
IL_000f:
// Exception count 1
.try IL_0003 to IL_0008 finally handler IL_0008 to IL_000d
} // end of method Class1::Test
异常对性能的影响
引用别人的数据，自己就不班门弄斧了
- 大佬的研究
https://www.cnblogs.com/huangxincheng/p/12866824.html - <.NET Core底层入门>
![image]()
总体来说，只要进入内核态。就没有开销低的。
CLS与非CLS异常(历史包袱)
在CLR的2.0版本之前，CLR只能捕捉CLS相容的异常。如果一个C#方法调用了其他编程语言写的方法，且抛出一个非CLS相容的异常。那么C#无法捕获到该异常。
在后续版本中，CLR引入了RuntimeWrappedException类。当非CLS相容的异常被抛出时,CLR会自动构造RuntimeWrappedException实例。使之与与CLS兼容
public static void Example2()
{
try
{
}
catch(Exception)
{
//c# 2.0之前这个块只能捕捉CLS相容的异常
}
catch
{
//这个块可以捕获所有异常
}
}
.NET 9 的改进
评论区有大佬提醒.NET 9 重写了异常处理机制，新实现基于 NativeAOT Runtime的异常处理模型。
https://learn.microsoft.com/zh-cn/dotnet/core/whats-new/dotnet-9/runtime#faster-exceptions
为什么要改进?
CoreCLR 的异常处理在 Windows 系统上基于 Windows 结构化异常处理（SEH），在 Unix 系统上则是对其进行粗略模拟。我们先把 Unix 版本放在一边，来描述一下 Windows 系统上的方式。异常处理，包括相关的栈展开以及对栈展开部分中所有函数的展开信息查找，都是在 Windows 操作系统内部执行的。操作系统会在每个托管代码帧上回调我们的runtime，以便它能检查特定的帧是否会处理异常，并沿途调用 finally 块以及处理异常的 catch 块。异常处理是一个两轮的过程，这意味着帧会被处理两次。第一轮查找处理异常的帧，同时构建异常堆栈跟踪信息。第二轮再次遍历所有帧，直至处理异常的帧，然后调用 catch 块。这一次，帧会被展开，它们的栈空间也会被回收。
由于结构化异常处理（SEH）也适用于 C++ 帧以及一些汇编辅助帧，所以即便在托管帧与原生帧交错的情况下，它也能透明地工作。
由于上述提到的结构化异常处理（SEH）是由操作系统执行这一事实，而且研究表明异常处理过程中的大部分时间都花费在操作系统代码上，所以我们很难去提升它的性能。
眼见为实
用户异常
硬件异常
对比.NET8的调用堆栈，是否发现了什么端倪？
没错，就是除了硬件异常没办法，一定要经过内核态抛出来(但流程也简化了很多，不再二次进入内核态)，用户态异常完全不进入内核。
异常捕获的流程由托管堆自行处理，而不再依赖系统API。这其中带来的巨大提升是显而易见的。
提供提升有多少？
大约是2-4倍的性能提升。
https://code-corner.dev/2024/04/14/NET-9-—-Exception-handling-performance/
但依旧不能将其用作控制流机制，也就是业务错误通过Exception抛出来。
相对不抛出异常，依旧慢得一逼。因此业务异常对性能要求非常高应该是return而不是Exception
浙公网安备 33010602011771号