[转]C++异常处理 10

 

finally块的总结性说明
我们已经明确区分了强制执行f i n a l l y块的两种情况：
• 从t r y块进入f i n a l l y块的正常控制流。
• 局部展开：从t r y块的过早退出（g o t o、l o n g j u m p、c o n t i n u e、b r e a k、r e t u r n等）强制控制转移到f i n a l l y块。
第三种情况，全局展开（ global unwind），在发生的时候没有明显的标识，我们在本章前面Func_SEHTerminate函数中已经见到。在Func_SEHTerminate的t r y块中，有一个对TermHappenSomeError函数的调用。TermHappenSomeError函数会引起一个内存访问违规（ memory access violation ），一个全局展开会使Func_SEHTerminate函数的f i n a l l y块执行。

由于以上三种情况中某一种的结果而导致f i n a l l y块中的代码开始执行。为了确定是哪一种情况引起f i n a l l y块执行，可以调用内部函数AbnormalTermination：这个内部函数只在f i n a l l y块中调用，返回一个B o o l e a n值。指出与f i n a l l y块相结合的t r y块是否过早退出。换句话说，如果控制流离开t r y块并自然进入f i n a l l y块，AbnormalTermination将返回FA L S E。如果控制流非正常退出t r y块—通常由于g o t o、r e t u r n、b r e a k或c o n t i n u e语句引起的局部展开，或由于内存访问违规或其他异常引起的全局展开—对AbnormalTermination的调用将返回T R U E。没有办法区别f i n a l l y块的执行是由于全局展开还是由于局部展开。但这通常不会成为问题，因为可以避免编写执行局部展开的代码。（注意内部函数是编译程序识别的一种特殊函数。编译程序为内部函数产生内联（i n l i n e）代码而不是生成调用函数的代码。例如， m e m c p y是一个内部函数（如果指定/ O i编译程序开关）。当编译程序看到一个对m e m c p y的调用，它直接将m e m c p y的代码插入调用m e m c p y的函数中，而不是生成一个对m e m c p y函数的调用。其作用是代码的长度增加了，但执行速度加快了。

在继续之前，回顾一下使用结束处理程序的理由：
• 简化错误处理，因所有的清理工作都在一个位置并且保证被执行。
• 提高程序的可读性。
• 使代码更容易维护。
• 如果使用得当，具有最小的系统开销。

异常处理程序
异常是我们不希望有的事件。在编写程序的时候，程序员不会想去存取一个无效的内存地址或用0来除一个数值。不过，这样的错误还是常常会发生的。C P U负责捕捉无效内存访问和用0除一个数值这种错误，并相应引发一个异常作为对这些错误的反应。C P U引发的异常，就是所谓的硬件异常（ hardware exception）。在本章的后面，我们还会看到操作系统和应用程序也可以引发相应的异常，称为软件异常（ software exception）。

当出现一个硬件或软件异常时，操作系统向应用程序提供机会来考察是什么类型的异常被引发，并能够让应用程序自己来处理异常。下面就是异常处理程序的语法：
__try
{
   file://保护块
}
__except(异常过虑器)
{
  file://异常处理程序
}
注意__ e x c e p t关键字。每当你建立一个t r y块，它必须跟随一个f i n a l l y块或一个e x c e p t块。一个try 块之后不能既有f i n a l l y块又有e x c e p t块。但可以在t r y - e x c e p t块中嵌套t r y - f i n a l l y块，反过来也可以。

异常处理程序代码初步
与结束处理程序不同，异常过滤器（ exception filter）和异常处理程序是通过操作系统直接执行的，编译程序在计算异常过滤器表达式和执行异常处理程序方面不做什么事。下面几节的内容举例说明t r y - e x c e p t块的正常执行，解释操作系统如何以及为什么计算异常过滤器，并给出操作系统执行异常处理程序中代码的环境。

本来想把代码全部写出来的，但是实在是写这边文挡化的时间太长了，所以接下来就只是做说明，而且try和except块比较简单。

尽管在结束处理程序的t r y块中使用r e t u r n、g o t o、c o n t i n u e和b r e a k语句是被强烈地反对，但在异常处理程序的t r y块中使用这些语句不会产生速度和代码规模方面的不良影响。这样的语句出现在与e x c e p t块相结合的t r y块中不会引起局部展开的系统开销

当引发了异常时，系统将定位到e x c e p t块的开头，并计算异常过滤器表达式的值，过滤器表达式的结果值只能是下面三个标识符之一，这些标识符定义在windows的Except. h文件中。标识符定义为：
EXCEPTION_CONTINUE_EXECUTION (–1)   Exception is dismissed. Continue execution at the point where the exception occurred.
EXCEPTION_CONTINUE_SEARCH (0)   Exception is not recognized. Continue to search up the stack for a handler, first for containing try-except statements, then for handlers with the next highest precedence.
EXCEPTION_EXECUTE_HANDLER (1)   Exception is recognized. Transfer control to the exception handler by executing the __except compound statement, then continue execution at the assembly instruction that was executing when the exception was raised.

下面将讨论这些标识符如何改变线程的执行。
下面的流程概括了系统如何处理一个异常的情况：(这里的流程假设是正向的)
*****开始 -> 执行一个CPU指令 -> {是否有异常被引发} -> 是 -> 系统确定最里层的try 块 -> {这个try块是否有一个except块} -> 是 -> {过滤器表达式的值是什么} ->异常执行处理程序 -> 全局展开开始 -> 执行except块中的代码 -> 在except块之后执行继续*****

EXCEPTION_EXECUTE_HANDLER
在异常过滤器表达式的值如果是EXCEPTION_EXECUTE_HANDLER，这个值的意思是要告诉系统：“我认出了这个异常。即，我感觉这个异常可能在某个时候发生，我已编写了代码来处理这个问题，现在我想执行这个代码。”在这个时候，系统执行一个全局展开，然后执行向except块中代码（异常处理程序代码）的跳转。在except块中代码执行完之后，系统考虑这个要被处理的异常并允许应用程序继续执行。这种机制使windows应用程序可以抓住错误并处理错误，再使程序继续运行，不需要用户知道错误的发生。但是，当except块执行后，代码将从何处恢复执行？稍加思索，我们就可以想到几种可能性:

第一种可能性是从产生异常的CPU指令之后恢复执行。这看起来像是合理的做法，但实际上，很多程序的编写方式使得当前面的指令出错时，后续的指令不能够继续成功地执行。代码应该尽可能地结构化，这样，在产生异常的指令之后的CPU指令有望获得有效的返回值。例如，可能有一个指令分配内存，后面一系列指令要执行对该内存的操作。如果内存不能够被分配，则所有后续的指令都将失败，上面这个程序重复地产生异常。所幸的是，微软没有让系统从产生异常的指令之后恢复指令的执行。这种决策使我们免于面对上面的问题。

第二种可能性是从产生异常的指令恢复执行。这是很有意思的可能性。如果在except块中
有这样的语句会怎么样呢：在except块中有了这个赋值语句，可以从产生异常的指令恢复执行。这一次，执行将继续，不会产生其他的异常。可以做些修改，让系统重新执行产生异常的指令。你会发现这种方法将导致某些微妙的行为。我们将在EXCEPTION_CONTINUE_EXECUTION一节中讨论这种技术。

第三种可能性是从except块之后的第一条指令开始恢复执行。这实际是当异常过滤器表达式的值为EXCEPTION_EXECUTE_HANDLER时所发生的事。在except块中的代码结束执行后，控制从except块之后的第一条指令恢复。