中断与异常模型图
-
内中断
内中断是由 CPU 内部事件引起的中断，通常是在程序执行过程中由于 CPU 自身检测到某些异常情况而产生的。例如，当执行除法运算时除数为零，或者访问了不存在的内存地址，CPU 就会产生内中断。- 硬件异常
CPU内部产生的异常事件- 故障Fault
故障是在指令执行过程中检测到的错误情况导致的内中断,比如空指针，除0异常，缺页中断等 - 自陷Trap
这是一种有意的内中断，是由软件预先设定的特殊指令或操作引起的。比如syscall,int 3这种故意设定的陷阱 - 终止abort
终止是一种比较严重的内中断，通常是由于不可恢复的硬件错误或者软件严重错误导致的，比如内存硬件损坏、Cache 错误等
- 故障Fault
- 用户异常
软件模拟出的异常，比如操作系统的SEH，.NET的OutOfMemoryException
- 硬件异常
-
外中断
外中断是由 CPU 外部的设备或事件引起的中断。比如键盘，鼠标，主板定时器。这些外部设备通过向 CPU 发送中断请求信号来通知 CPU 需要处理某个事件。外中断是计算机系统与外部设备进行交互的重要方式，使得 CPU 能够及时响应外部设备的请求，提高系统的整体性能和响应能力。- NMI（Non - Maskable Interrupt，非屏蔽中断）
NMI 是一种特殊类型的中断，它不能被 CPU 屏蔽。与普通中断（可以通过设置中断屏蔽位来阻止 CPU 响应）不同，NMI 一旦被触发，CPU 必须立即响应并处理。这种特性使得 NMI 通常用于处理非常紧急且至关重要的事件，这些事件的优先级高于任何其他可屏蔽中断。 - INTR（Interrupt Request，中断请求）
INTR 是 CPU 用于接收外部中断请求的引脚（在硬件层面）或者信号机制（在软件层面）。外部设备（如磁盘驱动器、键盘、鼠标等）通过向 CPU 的 INTR 引脚发送信号来请求 CPU 中断当前任务，为其提供服务。这是计算机系统实现设备交互和多任务处理的关键机制之一。
- NMI（Non - Maskable Interrupt，非屏蔽中断）
用户异常
C#的异常，在Windows平台下是完全围绕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来说，主要实现以下四个操作
-
捕获异常并抛出异常的位置
-
通过线程栈空间获取异常调用栈
线程的栈空间维护了整个调用栈，扫描整个栈空间即可获取。
windbg的k系列命令就是参考此原理。
- 获取元数据的异常处理表
一旦方法中有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之间的代码 - 枚举异常处理表，调用对应的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才会执行
- 重新抛出异常
在执行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 虽然在finally块中修改了result的值，但是return语句已经确定了要返回的值，finally块中的修改不会改变这个返回值。不过，如果返回的是引用类型），在finally块中修改引用类型对象的内容是会生效的
异常对性能的影响
引用别人的数据，自己就不班门弄斧了
- 大佬的研究
https://www.cnblogs.com/huangxincheng/p/12866824.html - <.NET Core底层入门>
总体来说，只要进入内核态。就没有开销低的。
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 { //这个块可以捕获所有异常 } } 
![洛谷 P11345 [KTSC 2023 R2] 基地简化 题解](http://www.itfaba.com/wp-content/themes/kemi/timthumb.php?src=http://www.itfaba.com/wp-content/themes/kemi/img/random/2.jpg&w=218&h=124&zc=1)
