PHP的异常机制的原理是什么？在PHP每一个可独立执行的op array最后的ZEND_HANDLE_EXCEPTION是用来干什么呢？

    让我们从一个问题说起，上周的时候，blue5tar提了一个问题：“对于下面的代码，onError明明执行了，但是onException却没有执行，为什么？”.

    <?PHP

    function onError（$errCode, $errMesg, $errFile, $errLine） {

    echo “Error Occurred ”;

    throw new Exception（$errMesg）；

    }

    function onException（$e） {

    echo $e->getMessage（）；

    }

    set_error_handler（“onError”）；

    set_exception_handler（“onException”）；

    /* 我从不会以我的名字命名文件， 所以这个文件不存在 */

    require（“laruence.PHP”）；

    运行结果：

    Error Occurred

    PHP Fatal error:  main（）： Failed opening required 'laruence.PHP'

    首先，我们要知道，Require在包含一个找不到的问题的时候，会前后抛出俩个错误。

    1. WARNING : 在PHP试图打开这个文件的时候抛出。

    2. E_COMPILE_ERROR : 从PHP打开文件的函数返回失败以后抛出。

    而我们知道，set_error_handler是不能捕获E_COMPILE_ERROR错误的：

    The following error types cannot be handled with a user defined function: E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR, E_COMPILE_WARNING, and most of E_STRICT raised in the file where set_error_handler（） is called.

    所以，在onError中，只能捕获到第一个WARNING错误，而在onError中抛出的异常，为什么没有被默认exception_handler捕获呢？

    这就要说说PHP的异常机制了。

    了解opcode（深入理解PHP原理之Opcodes的同学都知道，在PHP5.3以前，每一个可独立运行的op array（文件、函数、方法）的最后一条opcode都是ZEND_HANDLE_EXCEPTION,而这个opcode是做什么用的呢？

    原来在PHP中，当有异常被throw的时候，会跳到每一个op array的最后一行，来执行这条ZEND_HANDLE_EXCEPTION,伪码如下：

    void on_throw_exception（zval *exception TSRMLS_DC） {

    1. 判断是否已经有异常抛出

    2. 记录exception

    3. 记录下一条要执行的op line的序号

    4. 下一条要执行的op line序号 = 当前op array的最后一条

    }

    恩，就和改写ip寄存器一样，改写下一条要执行的op line的序号，就改变了程序的流向。这样，就会进入到了ZEND_HANDLE_EXCEPTION的处理逻辑中。

    而在ZEND_HANDLE_EXCEPTION中，会判断这个异常是否在try catch中。

    如果是，则把下一条要执行的op line,置为第一个catch的op line,并继续执行。

    如果不是，则销毁一些不需要的变量，和opline,然后直接结束执行过程。

    有的同学要问了：“那set_exception_handler设置的异常默认处理函数（user_exception_handler）什么时候起作用呢？”

    恩，是在执行完成退出执行LOOP以后才判断是否有默认异常处理函数，如果有才调用：

    //执行

    zend_execute（EG（active_op_array） TSRMLS_CC）；

    if （EG（exception）） {

    if （EG（user_exception_handler）） {

    调用用户定义的默认异常处理函数

    } else {

    未捕获的异常

    }

    } else {

    没有异常

    }

    destroy_op_array（EG（active_op_array） TSRMLS_CC）；

    efree（EG（active_op_array））；

    注： 图中有一处不严谨，即在确定是否最后一个catch块的时候，会同时判断（is_a），如果是才进入最后一个catch块执行。
 

    而PHP在遇到Fatal Error的时候，会直接zend_bailout,而zend_bailout会导致程序流程直接跳过上面代码段，也可以理解为直接exit了（longjmp），这就导致了user_exception_handler没有机会发生作用。

    了解到这些，我想文章开头的问题的为什么？也就很清晰了吧？

    最后，关于ZEND_HANDLE_EXCEPTION,也许有同学会有疑问：如果是这样，那为什么每一个可独立执行的op array最后都有这个ZEND_HANDLE_EXCEPTION呢？最简单的，如果一个函数中不会throw,那么这个opcode是明显不需要的啊？你很聪明，PHP 5.3开始，已经按照你的想法调整了。只有在throw时刻， 才会动态的生成ZEND_HANDLE_EXCEPTION opline.
 

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。