异常的使用

pda设备

异常的使用

不管是网络还是出版读物，关于 C# 异常系统性的资料都比较少，我所在的工控领域也很少有开发者使用异常。异常实际上是一种非常好的机制，很值得推广。为此我根据过往的学习积累，结合一些项目经验，撰写本文。
1. 为什么应该使用异常

在开始本文之前，我们先看一下常用的几种“报告错误”的方式：

• 方式一：返回错误码
  

缺点：

• 使用者不得不对返回值进行判断，导致“圈复杂度”增加；
  
• 如果方法需要返回值，返回内容不得不通过“out”参数传出。
  

下面是一段伪代码，我们可以看到使用错误码有诸多不便：
Client client = new Client();if (client.Connect() == 1){    if (client.Receive(out string content) == 1)    {        // 执行其他动作    }}class Client{    public int Connect()    {        // 执行其他动作        if (successeded)        {            // 执行成功，返回 1            return 1;        }        else        {            // 执行失败，返回错误码            return errorCode;        }    }    public int Receive(out string result)    {        if (successeded)        {            result = result;            return 1;        }        else        {            result = null;            return errorCode;        }    }}

• 方式二：全局属性记录错误信息
  

缺点：

• 需要对全局属性进行判断，使用者很容易遗漏；
  
• 同样会造成“圈复杂度”增加。
  

Client value = new Client();value.Connect();if (value.ErrorCode == 1){    string content = value.Receive();    if (value.ErrorCode == 1)    {        // 执行其他动作    }}class Client{    public int ErrorCode { get; private set; }    public void Connect()    {        // 执行其他动作        if (successeded)        {            // 执行成功，全局属性置为 1            ErrorCode = 1;            return;        }        else        {            // 执行失败，设置错误码            ErrorCode = errorCode;            return;        }    }    public string Receive()    {        if (successeded)        {            ErrorCode = 1;            return result;        }        else        {            ErrorCode = errorCode;            return null;        }    }}上述两种机制不光使用繁琐，返回错误码在部分没有返回值的场景下还无法使用：

• 构造函数执行失败
  
• 设置属性值执行失败
  

而异常刚好可以弥补这些缺陷。

Info
《框架设计指南》这本书对异常的好处进行了详细的阐释，我在这里进行引述（有删改）：

• 异常与面向对象语言结合精密。就构造函数、运算符重载和属性而言，开发者无法选择返回值。出于这个原因，对于面向对象的框架来说，基于返回值的错误报告是不可能标准化的。
  
• 异常促进了 API 的一致性，因为它们只被设计用于错误报告。相比之下，返回值有很多用途，错误报告只是其中一个子集。出于这个原因，尽管异常可以被限制在特定的模式中，然而通过返回值报告错误的 API 很可能会利用大量的模式。Win32 API 就是这种不一致的一个典型例子：它使用了 BOOL、HRESULTS 和 GetLastError 等。
  
• 在基于返回值的错误报告中，错误处理代码总是被放置在靠近故障点的地方。然而，对于异常处理，应用程序的开发者可以有自己的选择，他们既可以在故障点附近捕获异常，也可以将错误处理代码集中在调用栈的更上方。
  
• 错误处理代码更容易被本地化。如果通过返回值报告错误的代码非常健壮，则往往意味着几乎每一行功能代码中都有一个 if 语句。这些 if 语句用于处理失败的情况。有了基于异常的错误报告，通常可以这样书写健壮的代码：顺序执行多个方法或操作，然后在 try 语法块后面按组去处理错误，甚至可以在调用栈更高层级位置处理错误。
  
• 错误码很容易被忽略掉，并且在大多数情况下都是如此。
  
• 异常携带的丰富信息可描述导致错误的原因。
  
• 异常允许面向未经处理异常的处理器。
  这里的“未经处理异常的处理器”指诸如 Application.DispatcherUnhandledException​、Application.ThreadException​ 支持订阅全局的异常处理事件。
  
• 异常促进工具的发展。异常是一种定义明确的方法失败模型。正因为如此，调试器、分析器、性能计数器等工具才有可能密切关注异常。
  

2. 异常的使用示例

上一节的伪代码改为使用异常后如下：
try{    Client value = new Client();    value.Connect();    string content = value.Receive();}catch (Exception ex){    Console.WriteLine(ex.Message);}class Client{    public void Connect()    {        // 执行其他动作        if (successeded)        {            return;        }        else        {            // 执行失败，抛出异常            throw new InvalidOperationException("因...，连接失败。");        }    }    public string Receive()    {        if (successeded)        {            return result;        }        else        {            throw new InvalidOperationException("因...，接受数据失败。");        }    }}前面我们还提到返回错误码无法在没有返回值的场景下使用，下面是在构造函数和属性 setter 中使用异常的一个简单示例：
class Client{    public bool IsConnected { get; private set; }    private string _hostname;    private int _port;    // 通过异常限制 Hostname 和 Port 只能在未连接状态下修改。    public string Hostname    {        get => _hostname;        set        {            if (IsConnected)            {                throw new InvalidOperationException("客户端处于连接状态，无法修改主机名称。");            }            _hostname = value;        }    }    public int Port    {        get => _port;        set        {            if (IsConnected)            {                throw new InvalidOperationException("客户端处于连接状态，无法修改端口。");            }            _port = value;        }    }    public Client(string hostname, int port)    {        if (string.IsNullOrWhiteSpace(hostname))        {            throw new ArgumentException("参数无效。", nameof(hostname));        }        Hostname = hostname;        Port = port;    }    public void Connect()    {        IsConnected = true;    }}可以看到，通过异常反馈执行错误代码更为整洁，并且能通过异常的 Message​ 属性报告错误信息。
3. 应该抛出哪个异常？

对于异常，简单使用并不复杂。但是异常的种类繁多，开发者常常困惑应该抛出哪个异常。异常和错误相关，错误一般分为两类：

• 使用错误
  
• 执行错误
  又分为两类：
  
  
  
  • 程序错误
    
  • 系统失败
    
  
  

使用错误：错误调用导致的错误，例如传入了 null 参数。此类错误不应该由框架处理，而应该修改调用方代码。
此类错误对应的常用异常有 3 个：

• ​ArgumentException​：ArgumentNullException​ 和 ArgumentOutOfRangeException​ 的基类，用于表示传入的参数错误
  
• ​ArgumentNullException​：参数为空异常，当传入方法的参数为 null，应该抛出该异常
  
• ​ArgumentOutOfRangeException​：参数值超出范围异常，当传入方法的参数超过限定范围，应该抛出该异常
  

下面是一个简单的示例：
class Client{    public void Connect(string hostname, int port)    {        if (string.IsNullOrWhiteSpace(hostname))        {            throw new ArgumentException("参数无效。", nameof(hostname));        }        // 执行其他操作    }}执行错误-程序错误：可以在程序中处理的错误。如 File.Open​ 未找到相应文件抛出 FileNotFoundException​ 异常，我们可以创建一个新文件并继续运行。
此类错误对应的异常有很多，最常用的异常是：

• ​InvalidOperationException​：对象处于不正确的状态时，抛出该异常
  

下面是一个简单的示例：
class Client{    public bool IsConnected { get; private set; }    public void Connect()    {        if (IsConnected)        {            throw new InvalidOperationException("客户端已连接。");        }        // 其他操作        IsConnected = true;    }}执行错误-系统失败：无法在程序中进行处理的执行错误。如即时编译器（Just-In-Time compiler）用尽了内存而引发的 OutOfMemoryException​。
此类错误对应的异常也有很多，但是这些异常都不应该由开发者抛出，而是由 CLR 负责。例如：

• ​OutOfMemoryException​：内层分配失败时抛出该异常，只有 CLR 才能抛出该异常
  

Info
关于更多的异常分类，见第7章 异常 - hihaojie - 博客园 7.3 标准异常类型的使用

4. 异常的捕捉

有抛出，自然有捕捉。异常的捕捉并不复杂，不过仍然有诸多细节需要注意。这里我们通过几个问题厘清异常的捕捉。我们假设有如下 Connect()​ 方法：
void Connect(string hostname){    if (hostname is null)    {        throw new ArgumentNullException(nameof(hostname));    }    // 执行其他操作}这里先提一点：ArgumentException​ 是 ArgumentNullException​ 和 ArgumentOutOfRangeException​ 的父类。

• 问题一：如下三段代码，哪段可以通过编译？
  

// 代码1try{                Connect(null!);}catch (ArgumentException ex){    Console.WriteLine("捕捉到 ArgumentException 异常");}catch (ArgumentNullException ex){    Console.WriteLine("捕捉到 ArgumentNullException 异常");}// 代码2try{    Connect(null!);}catch (ArgumentNullException ex){    Console.WriteLine("捕捉到 Exception 异常");}catch (ArgumentException ex){    Console.WriteLine("捕捉到 ArgumentException 异常");}// 代码3try{    Connect(null!);}catch (ArgumentNullException ex){    Console.WriteLine("捕捉到 Exception 异常");}catch (ArgumentException ex){    Console.WriteLine("捕捉到 ArgumentException 异常");}catch (InvalidOperationException ex){    Console.WriteLine("捕捉到 InvalidOperationException 异常");}

• 问题二：如下代码会输出“捕捉到 ArgumentException 异常”吗？
  

try{    Connect(null!);}catch (ArgumentException ex){    Console.WriteLine("捕捉到 ArgumentException 异常");}

• 问题三：如下代码会输出哪条信息？
  

try{                  SentMessage("异常测试。");}catch (ArgumentException ex){    Console.WriteLine("捕捉到 ArgumentException 异常");}void SentMessage(string message){    try    {        Connect(null!);    }    catch (ArgumentOutOfRangeException ex)    {        Console.WriteLine("捕捉到 ArgumentOutOfRangeException 异常");    }}‍
通过上述问题我们可以得出如下结论：

• 要捕捉的异常存在父子关系时，需要子类异常在前，父类异常在后，否则无法编译；
  
• 子类异常可以通过捕捉父类异常完成捕捉；
  ​Exception​ 作为所有异常的基类，捕捉它可以捕获全部异常。
  
• 未捕获的异常会进一步向上抛出；
  

‍
对应的，捕捉异常有这些惯例（准则）：

• 处理方式相同的异常，可以捕获它们共同的父类；
  

如“使用错误”异常（ArgumentException​ 三兄弟），它们的处理方式相同（应由调用者修改代码），可以直接捕获 ArgumentException​ 异常进行处理。
类似的还有 OperationCanceledException​ 和 TaskCanceledException​

• 只捕获知道如何处理的异常；
  

对于未知的异常，应该进一步向上抛出，由上一级进行处理。
如下代码演示了处理已知异常 TimeoutException​，忽略未知异常 ArgumentNullException​
try{                Connect(hostname);}catch (TimeoutException ex){    Console.WriteLine("连接超时，尝试二次连接");    Connect(hostname);}void Connect(string hostname){    if (hostname is null)    {        throw new ArgumentNullException(nameof(hostname));    }    // 执行其他操作    if (usedTime > TimeSpan.FromSeconds(100))    {        throw new TimeoutException("连接用时超过 100s。");    }}5. 异常的捕捉、再抛出

有时我们捕捉异常后并不想处理，而是想进行记录并二次抛出，或者将转为其他异常再抛出。我们先比较如下三段代码，看看它们的二次抛出有何不同：
Exception holder = null;try{    try    {        throw new Exception("原始异常");    }    catch (Exception ex)    {        Console.WriteLine(ex.StackTrace);        holder = ex;        throw;    }}catch (Exception ex){    Console.WriteLine(ex.Message);    Console.WriteLine(ex.StackTrace);    Console.WriteLine(holder == ex);}Exception holder = null;try{    try    {        throw new Exception("原始异常");    }    catch (Exception ex)    {        Console.WriteLine(ex.StackTrace);        holder = ex;        throw ex;    }}catch (Exception ex){    Console.WriteLine(ex.Message);    Console.WriteLine(ex.StackTrace);    Console.WriteLine(ex == holder);}Exception holder = null;try{    try    {        throw new Exception("原始异常");    }    catch (Exception ex)    {        Console.WriteLine(ex.StackTrace);        holder = ex;        throw new Exception("二次抛出异常", ex);    }}catch (Exception ex){    Console.WriteLine(ex.Message);    Console.WriteLine(ex.StackTrace);    Console.WriteLine(holder == ex);}执行上述代码我们可以发现：

• 直接使用 throw​ 二次抛出：Exception.StackTrace​ 属性会保留原始栈信息；
  
• 使用 throw ex​ 二次抛出：二次抛出的异常与原实例相同，但 Exception.StackTrace​ 存储的栈信息更新为二次抛出的位置；
  
• 使用 throw new Exception()​ 二次抛出：将异常进行了二次包装，Exception.Message​、Exception.StrackTrace​ 等诸多成员值都发生了变化。
  

‍
我们可以根据需要采用相应的二次抛出方式，不过一般会遵循如下准则：

• 若不需要二次包装异常，应直接使用 throw​ 二次抛出；
  
• 若需要二次包装异常，应使用 throw new SomeException​ 二次抛出异常，并将原异常传入新异常。
  

‍
你可能对“并将原异常传入新异常”这句话感到困惑。这里我们看一下基类异常 Exception​ 的四个构造函数：
public Exception();public Exception(string message)public Exception(string message, Exception innerException)protected Exception(SerializationInfo info, StreamingContext context)其中第三个构造函数 Exception(string message, Exception innerException)​ 需要一个 Exception​ 实例，是的，该参数是专门用于二次包装异常。当我们需要将原异常包装为其他异常时，需要将原异常实例通过该参数传入。二次包装时不传入该参数也是可以的，不过传入是标准做法，有利于开发者追溯原异常。下面是一个简单示例：
try{    throw new TimeoutException("执行超时。");}catch (Exception ex){    throw new InvalidOperationException("执行失败，请检查硬件状态。", ex);}6. 常见异常

下面我们介绍一下常见的异常，以及它们的使用场景。
6.1 基类异常

如下异常因表达的异常分类不明确，开发者不应抛出下列异常：

• ​Exception​：基类异常，它是所有异常的基类。我们自定义异常时需要派生自该类或其子类。
  
• ​ApplicationException​ 和 SystemException​：设计之初，SystemException​ 的派生类用于表示 CLR（或系统）自身抛出的异常，ApplicationException​ 的派生类用于表示非 CLR 异常（应用程序异常）。但是很多异常类没有遵循这一模式，如 TargetInvocationException​ 派生自 ApplicationException​，却由 CLR 抛出。因此 ApplicationException​ 已失去原有意义。
  

我们在自定义异常时，不再推荐以 ApplicationException​、SystemException​ 为基类。
6.2 常用异常

• ​InvalidOperationException​：如果对象处于不正确的状态，抛出该异常。
  例如：往只读的 FileStream​ 写入数据。
  
• ​ArgumentException​、ArgumentNullException​、ArgumentOutOfRangeException​：用户传入错误参数时，要抛出 ArgumentException​ 或其派生类，并设置 ParamName​ 属性。如果可以，尽量选择位于继承层次末尾的异常类型。
  
• ​OperationCanceledException​、TaskCanceledException​：表示操作被取消。TaskCanceledException​ 用于异步编程，OperationCanceledException​ 可用于任意场景。
  需要注意的是，在异步方法中手动抛出 TaskCanceledException​ 时，需要通过其构造函数传入 CancellationToken​，否则相应的 Task​ 的 Status​ 属性不会标记为 Canceled​
  
• ​FormatException​：表明文本解析方法中的输入字符串不符合要求或指定格式。
  
• ​FileNotFoundException​：表示文件未找到。
  
• ​InvalidCastException​：表示无效的类型转换，常见于强制转换、拆箱。
  如下代码便会抛出该异常：
  object content = string.Empty;int value = (int)content;
  
• ​NotSupportedException​：表示当前成员功能不支持。
  以 ReadOnlyCollection<T>​ 为例，它不支持 Add()​ 方法，但又实现了 IList<T>​ 接口，因此它的 Add()​ 方法便抛出了该异常。
  
• ​NotImplementedException​：表示当前成员功能尚未实现。
  
• ​TimeoutException​：表示执行超时。因历史遗留原因，Web 通信超时并未抛出该异常。以 WebRequest​ 为例，它通信超时会抛出 WebException​ 异常，并令异常实例的 Status​ 属性值为 WebExceptionStatus.Timeout​ 枚举值。
  

6.3 CLR 异常

这类异常通常由 CLR 抛出，开发者不应该使用这些异常。

• ​NullReferenceException​、IndexOutOfRangeException​、AccessViolationException​：表示代码存在缺陷，需要开发者调整代码。
  
• ​StackOverflowException​：栈溢出时会抛出该异常，常见于无限递归。栈溢出时，几乎不可能让托管代码保持状态一致。发生该异常 CLR2.0 默认会让程序立即终止。开发者也不应该捕获该异常（是的，此时应该纵容程序崩溃）。
  
• ​OutOfMemoryException​：内存分配失败时会抛出该异常。
  

7. 如何自定义异常

上一节我们讲了诸多预定义异常，当预定义异常不能满足我们的需要时，就需要自定义异常了。
自定义异常通常遵循如下准则：

• 自定义异常应该派生自 System.Exception​ 或其他常用的基类异常；
  
• 继承层次不应该过深；
  
• 命名使用“Exception”后缀；
  
• 如果多种错误可以通过一种方式来处理，则它们应该属于同一类型的异常；
  
• 自定义异常应该至少有如下 4 个构造函数：
  public class SomeException : Exception, ISerializable{    public SomeException();    public SomeExcepiton(string message);    public SomeExcepiton(string message, Exception inner);    // 序列化所需构造函数    protected SomeException(SerializationInfo info, StreamingContext context);}
  

Tips
关于自定义异常必须实现二进制序列化（即实现 SomeException(SerializationInfo info, StreamingContext context)​ 构造函数）在新版 .NET 中已不再要求，且 Exception(SerializationInfo info, StreamingContext context)​ 也被标记为了弃用（[Obsolete]​）。因此下面的例子忽略了二进制序列化的实现。

‍
现在，我们假设有这么一个硬件设备：

• 它是一个测距仪，计算机通过 TCP/IP 的方式与它通信（它是服务端）；
  
• 当它正在测量中，重复发送测量指令它不会进行响应（即会发生通信超时）；
  
• 如果测量的距离超出返回，它会返回“OutOfRange”字符串；
  
• 测量成功，则会返回数值，表示测得的距离。
  

这里我们要自定义一个 DeviceErrorException​ 表示操作该硬件时的一切异常。请思考，该测距仪的类应该怎样定义？该异常又怎样定义？
‍
下面是我编写的一个测距仪类和对应的 DeviceErrorException​ 异常，大家可以作为参考：
class Measurer{    private TcpClient _client;    public bool IsConnected => _client != null && _client.Connected;    private const string Command = "Measure";    private const string OutOfRangeResponse = "OutOfRange";    public void Connect(string hostname, int port)    {        try        {            _client = new TcpClient(hostname, port);        }        catch (TimeoutException ex)        {            throw new DeviceErrorException("连接超时。", ex, DeviceState.Timeout);        }    }      public double Measure()    {        try        {            if (!IsConnected)            {                throw new DeviceErrorException("测距仪尚未连接。请连接后再进行操作。", DeviceState.NotConnected);            }            byte[] writeBuffer = Encoding.ASCII.GetBytes(Command);            Stream stream = _client.GetStream();            _client.GetStream().Write(writeBuffer, 0, writeBuffer.Length);                    byte[] readBuffer = new byte[100];            int count = stream.Read(readBuffer, 0, readBuffer.Length);            string content = Encoding.ASCII.GetString(readBuffer, 0, count);            if (content == OutOfRangeResponse)            {                throw new DeviceErrorException("数据读取失败，超出测量范围。", DeviceState.OutOfRange);            }            if (double.TryParse(content, out double result))            {                return result;            }            throw new DeviceErrorException($"转换数据失败。获取的内容为：[{content}]", DeviceState.DataParseError);        }        catch (TimeoutException ex)        {            throw new DeviceErrorException("通信超时。", ex, DeviceState.Timeout);        }        catch (DeviceErrorException)        {            throw;        }        catch (Exception ex)        {            throw new DeviceErrorException("未知异常。", ex);        }    }}class DeviceErrorException : InvalidOperationException{    public DeviceState State { get; }    public DeviceErrorException() : this(DeviceState.Unknown)    { }    public DeviceErrorException(DeviceState state)    {        State = state;    }      public DeviceErrorException(string message) : this(message, DeviceState.Unknown)    { }    public DeviceErrorException(string message, DeviceState state) : base(message)    {        State = state;    }      public DeviceErrorException(string message, Exception innerException) : this(message, innerException, DeviceState.Unknown)    { }      public DeviceErrorException(string message, Exception innerException, DeviceState state) : base(message, innerException)    {        State = state;    }}enum DeviceState{    Unknown,    DataParseError,    NotConnected,    Timeout,    OutOfRange,}8. 异常和性能

一些开发者不愿意使用异常的一个重要原因便是：影响性能（个人决定有点无稽之谈，至少在工控领域我觉得这点性能损失完全不必要担心）。
《框架设计指南》中提到：当抛出异常的频率高于每秒 100 个时，极有可能会带来显著的性能影响。此时我们可以使用“测试者-执行者模式”，或“Try 模式”，这两种模式在 .NET 中十分常见。
8.1 测试者-执行者模式：

我们以集合为例。以下代码我们并不知道 numbers​ 是否是只读集合，因此它有可能抛出 NotSupportException​：
ICollection<int> numbers = ...numbers.Add(1);​ICollection<T>​ 刚好定义了 IsReadOnly​ 属性，我们可以先通过它判断集合是否是只读的，再进行 Add 操作：
ICollection<int> numbers = ......if (!numbers.IsReadOnly){    numbers.Add(1);}其中，IsReadOnly​ 是“测试者”，Add()​ 方法是“执行者”。
在“7. 如何自定义异常”中，我定义的 Measurer​ 类也添加了 IsConnected​ 属性，用于告知硬件是否已连接，这也是一种“测试者-执行者模式”。

Notice
在多线程中使用该模式可能出现“竞态条件”，使用时要多加注意。

8.2 Try 模式

Try 模式的使用更加常见，如 int.TryParse()​、Dictionary<TKey, TValue>.TryGetValu()​ 等方法。
以 DateTime​ 的 Try 模式为例，大致形式如下：
public struct DateTime{    public static DateTime Parse(string dateTime) { ... }    public static DateTime TryParse(string dateTime, out DateTime Result) { ... }}Try 模式有诸多细节需要注意：

• 如果成员在常用代码中都可能抛出异常，应使用 Try-Parse 模式避免因异常引起的性能问题。
  
• Try-Parse 模式要使用“Try”前缀，用 bool 作为返回类型。
  
• Try 方法返回 false​ 的原因只有一种，其余类的失败则要抛出异常。
  
• 要为 Try 方法提供等价抛出异常的方法。
  如 DateTime.TryParse()​ 的等价方法 DateTime.Parse()​
  
• 要通过 out 参数，返回 Try 方法的值。
  
• 要在 Try 方法返回 false 时，将 default(T) 赋值给 out 参数。
  
• 避免在抛出异常时向 Try 方法的 out 参数写入数据。
  

9. 怎么处理“不知道如何处理”的异常

当你调用的接口抛出了未知异常，应该怎么处理？答案可能出乎大多数人的意料：不要捕捉它，让程序崩溃是最好的解决方案。《框架设计指南》中有这么一段话：

你的应用程序应该只处理它理解的那些异常。一般来说，在“某物”出问题之后，几乎不可能把应用程序从可能已被破坏的状态恢复到正常状态，此时只需处理那些你的应用程序可以合理响应的异常。对于其他所有的异常，无需处理，操作系统可中止你的应用程序。

如果你认为当前应用程序已处于带病状态、它不应该继续运行，此时建议通过调用 System.Enviroment.FailFast()​ 方法来中止进程，而不是抛出异常。该方法接受一个 string 参数，我们可以通过该参数传递错误信息。这个错误信息最终会被操作系统记录在“计算机管理→系统工具→事件查看器→Windows 日志→应用程序”中。因未捕获异常导致的程序崩溃，其崩溃信息也会记录在此处。
最后，根据 Windows 日志信息，进一步排查程序崩溃原因，进行针对性修复。
​Enviroment.FailFast()​ 的用法如下：
Enviroment.FailFast("发生了一个无法挽回的异常", ex)10. 转移异常

有时我们捕捉到异常并不想直接处理，又不想抛出，而是想转移至其他线程。使用一个字段/属性记录该异常，再在主线程抛出？不是很合适，这会破坏原有的调用栈信息。
.NET 早有预备，它提供了 ExceptionDispatchInfo​ 类，专门用于转移异常：
当从其他线程转移异常，或者 catch 后未使用空的 throw 语句再次抛出异常，要使用 ExceptionDispatchInfo​ 类，它会在重新抛出的过程中持续保存调用栈。下面是一个简单的用例：
private ExceptionDispatchInfo _savedExceptionInfo;private void BackgroundWorker() {    try{        ...    } catch (Exception e){        _savedExceptionInfo = ExceptionDispatchInfo.Capture(e);    }}public object GetResult() {    if(_done) {        if(_savedExceptionInfo != null){            _savedExceptionInfo.Throw();            // 编译器无法理解该方法是抛出了一个异常，因此需要额外的return语句。            return null;        }    }}11. 过滤异常

异常过滤器（exception filter）于 C#6 引入。通过异常过滤器我们可以重复捕获同类型异常：
catch (WebException ex) when (ex.Status == WebExceptionStatus.Timeout){ ... }catch (WebException ex) when (ex.Status == WebExceptionStatus.NameResolutionFailure){ ... }when 子句中的布尔表达式可以包含副作用，例如调用一个方法记录诊断所需的异常的日志。
它的使用也有陷阱。试分析如下代码会发生什么：
try{              throw new ArgumentException();}catch (ArgumentException ex) when (ex.ParamName == string.Empty){    Console.WriteLine("命中第一个 when 子句");}catch (ArgumentException ex) when (ex.ParamName is null){    Console.WriteLine("命中第二个 when 子句");}答案是：会输出“命中第二个 when 子句”。
你可能会疑惑：它不应该在第一个 when 字句那里抛出异常吗？毕竟 ParamName 属性未赋值，进行相等判断时应该抛出 NullReferenceException​ 才对。这是因为在过滤器中引发异常时，该异常由 CLR 捕获，并且该过滤器返回 false。该行为无法和过滤器执行并返回 false 区分开，因此很难进行调试。使用时要多加注意
12. 其他事项

12.1 切勿随意修改异常名称及其父类

我们前面提到：

处理方式相同的异常，可以捕获它们共同的父类

这意味着我们不应该随意修改自定义异常的基类，否则原有的异常处理代码无法正常工作。以如下代码为例，因基类异常由 InvalidOperationException​ 改为 Exception​，原有的异常处理代码不再起作用：
// 原异常// class MyException : InvalidOperationException { }// 修改基类后的异常class MyException : Exception { }// 原本可以正常运作的异常处理代码失效try{                throw new MyException();}catch (InvalidOperationException ex){    Console.WriteLine("捕捉到 InvalidOperationException 或其子类异常");}12.2 捕捉后仍会向上抛出的异常：ThreadAbortException​

提到多线程显然离不开 Thread​。Thread​ 的 Abort()​ 方法用于终止相应线程，被终止的线程会抛出 ThreadAbortException​ 异常。不过该异常较为特别，捕捉后会继续向上抛出。试分析如下代码，会发生什么：
Thread thread = new Thread(DoSomething);thread.Start();Thread.Sleep(100);thread.Abort();void DoSomething(){    try    {        try        {            while (true)            {                Thread.Sleep(20);            }        }        catch (ThreadAbortException ex)        {            Console.WriteLine("第一次捕获到 ThreadAbortException 异常");        }    }    catch (ThreadAbortException ex)    {        Console.WriteLine("第二次捕获到 ThreadAbortException 异常");    }}答案是：它会依次输出“第一次捕获到 ThreadAbortException 异常”、“第二次捕获到 ThreadAbortException 异常”。若想终止该异常进一步向外抛出，需调用 Thread.ResetAbort()​ 方法，它会将线程状态（ThreadState​）从 AbortRequested​ 恢复至 Running​。
<hr>参考文献：

• 《框架设计指南：构建可复用.NET库的约定、惯例与模式》第三版
  
• 《C#7.0 核心技术指南》
  

Info
上述两本书的部分内容，可参阅我的阅读笔记阅读笔记目录汇总 - hihaojie - 博客园

‍