25.02.04 《CLR via C#》 笔记 13

核心机制

第二十章 异常和状态管理

1. 什么是异常：异常指成员没有完成它的名称所宣称的行动；异常是程序运行过程中用来表示错误并处理的机制，错误可以是更广义的，包括程序中未捕获的问题或逻辑缺陷。
2. 异常处理机制（try-catch-finally结构）
   1. try块：放入可能引发异常的代码（需要得体的进行恢复和/或清理的代码）；一个try块至少要有一个关联的catch块或finally块；一个try块中放多少代码取决于状态管理，如果一个try块中执行多个可能抛出同一个异常类型的操作，但不同的操作有不同的异常恢复措施，就应该每个操作放在自己的try块中；尽量将 try块的范围缩小到只包含可能会引发异常的代码。
   2. catch块：负责异常恢复的代码；如果try块中的代码没有抛出异常就不会执行catch块
   3. catch关键字后的圆括号中的表达式称为捕捉类型，捕捉类型必须是System.Exception或它的派生类型；CLR自上而下搜索匹配的catch块，所以较具体的异常应放在顶部（如果放反，编译器会因无法抵达报错）
   4. try块中的代码抛出异常时，CLR搜索类型与抛出的异常相同的catch块，如同没有则去调用栈更高一层搜索，如果到了调用栈的顶部还是没有，则抛出未处理的异常
   5. 一旦CLR找到匹配的catch块，就会执行内层所有finally块中的代码：CLR 会按照调用栈逐步寻找匹配的catch块，寻找过程中每次离开一个try块，都会执行该try块对应的finally块中的代码。内层finally块执行完毕后，匹配到异常的catch块中的代码才会开始执行，该块的finally还要等这个catch块执行完毕才会执行
   6. 在catch块的末尾，我们可以选择:
      1. 重新抛出相同的异常
      2. 抛出一个不同的异常
      3. 从catch块退出(进入finally)
   7. C#允许在捕捉类型后指定一个变量，catch块的代码可以引用这个变量来访问异常的具体信息（如stack trace）；这个变量可以修改，但最好把它当作只读的
   8. finally块：保证会执行的代码，一般用于资源清理
   9. finally块不是必须的，但只能出现一个且必须在所有catch块之后；执行完finally后，会执行紧跟finally之后的语句
3. CLR允许抛出任何类型的实例，但CLS规定必须能抛出和捕捉派生自System.Exception类型的异常
4. 访问Exception的StackTrace属性实际会调用CLR中的代码，初始化Exception对象时，StackTrace被初始化为null；一个异常抛出时，CLR记录抛出的位置（throw指令），一个catch块捕捉到异常时，CLR记录捕捉位置，访问StackTrace属性会创建一个字符串指出从抛出位置到捕捉位置的所有方法
5. 当一个异常被抛出或者重新抛出时，Windows 会处理异常的堆栈起点：如果一个异常成为未处理的异常，那么向windows error reporting报告的栈位置就是最后一次抛出或重新抛出的位置（而不是异常实际发生的地方）
6. 要获取完整的堆栈跟踪，需要用到StackTrace类，可以使用Exception对象构造
7. 实现自己的方法时抛出异常，要考虑：应该选择一个有意义的Exception派生类型，不要抛出Exception类型；向异常类型的构造器传入详细说明为什么无法完成任务的字符串消息
8. 定义自己的异常类，要注意：定义浅而宽的异常类型层次结构；类型应该可序列化
9. 错误不经常发生，开发人员不去追求完全可靠的代码，牺牲一定的可靠性来换取程序员开发效率的提升
10. 如果确定状态已经损坏到无法修复的程度，应该销毁所有损坏的状态，防止它造成更多的伤害，然后重启程序，重新初始化到良好的状态
11. 如果整个进程需要终止，应该使用Environment.FailFast方法，这个方法终止进程时，不会运行任何活动的try/finally块或Finalize方法，它将消息字符串和可选的异常写入windows application事件日志、生成Windows错误报告、创建内存转储（dump），然后终止当前进程
12. 设计规范（类库开发人员不要想当然地决定错误情形，应该让调用者自己决定）
    1. 使用finally块清理已成功的操作，再返回至调用者或者执行之后的代码；利用finally块显式释放对象以避免资源泄露；使用lock、using、foreach、析构器时，编译器会自动生成try/finally块
    2. 不要什么都捕捉（不要捕捉了System.Exception后不再抛出），否则应用程序不知道出了什么错，还会继续运行
    3. 一些可以预料的异常，可以得体地从异常中恢复并继续运行
    4. 发生不可恢复的异常时，回滚部分完成的操作
    5. 为隐藏实现细节，捕捉一个异常并重新抛出不同的异常（不利于调试，慎用）
13. 异常抛出时，没有任何catch块匹配抛出的异常类型，就发生一个未处理的异常。进程中的任何线程有未处理的异常，都会终止进程，windows会向事件日志写一条记录。
14. 异常处理是必须的，同时也是有代价的；频繁调用但频频失败的方法抛出异常所造成的性能损失可能是无法接受的；定义类型的成员时，应确保在一般使用情形中不会失败，只有当用户因抛出异常对性能不满意时才考虑添加一些TryXXX方法，帮助改善性能。（例Int32的Parse和TryParse方法）
15. 约束执行区域（CER）用于在某些特殊场景下保证代码的执行具有更高的可靠性，即使在不可控的异常（如内存不足或线程被终止）发生时，也能尽可能确保特定的代码能够完整执行（普通的异常处理机制try-catch-finally在面对某些不可控异常时可能会失败，而 CER 提供了额外的安全性）。
    1. RuntimeHelpers.PrepareConstrainedRegions() 用于定义 CER 的起始点，通知 CLR 在进入 CER 前准备好所有资源（CER 中所有可能执行的代码都会在进入 CER 前完全 JIT 编译）。
    2. ReliabilityContractAttribute 用于标记方法的可靠性契约，声明某个方法在 CER 内部的行为
    3. 但是，编译器和CLR并不验证代码是否符合ReliabilityContractAttribute 作出的保证
16. 代码协定(Code Contracts)用于定义代码的行为和约束条件，可以将前条件、后条件、对象不变性想象为方法签名的一部分。代码协定本质上是对代码逻辑的一个明确声明，这些声明可以在运行时检查，也可以在静态分析中验证。现在一般用断言（Assertions）进行条件验证。