深入理解PHP之异常机制
PHP的异常机制的原理是什么?
在PHP每一个可独立执行的op array最后的ZEND_HANDLE_EXCEPTION是用来干什么呢?
让我们从一个问题说起, 上周的时候, blue5tar提了一个问题:”对于下面的代码, onError明明执行了, 但是onException却没有执行, 为什么?”.
- <?php
- function onError($errCode, $errMesg, $errFile, $errLine) {
- echo "Error Occurred\n";
- 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));
而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.
Changed exception handling. Now each op_array doesn’t contain ZEND_HANDLE_EXCEPTION opcode in the end. (Dmitry)
建议继续学习:
- PHP的异常原理与实例说明 Fatal error: Uncaught exception (阅读:8821)
- 是返回错误码,还是抛出异常?说说我的选择 (阅读:5878)
- Perl 异常处理之 autodie 和 Try::Tiny (阅读:2619)
- PHP程序员也要学会使用“异常” (阅读:2568)
- 异常的代价 (阅读:2445)
- 僵尸对象或 RAII (阅读:2416)
- PHP错误处理及异常处理 (阅读:2460)
- 我们什么时候应该使用异常? (阅读:2349)
- Java处理InterruptedException异常小结 (阅读:1736)
- Swift错误和异常处理 (阅读:813)
扫一扫订阅我的微信号:IT技术博客大学习
- 作者:雪候鸟 来源: 风雪之隅
- 标签: set_error_handle set_exception_ha ZEND_HANDLE_EXCE 异常
- 发布时间:2010-08-03 23:51:28
- [65] Oracle MTS模式下 进程地址与会话信
- [64] Go Reflect 性能
- [64] 如何拿下简短的域名
- [59] IOS安全–浅谈关于IOS加固的几种方法
- [58] 【社会化设计】自我(self)部分――欢迎区
- [58] 图书馆的世界纪录
- [56] android 开发入门
- [53] 视觉调整-设计师 vs. 逻辑
- [46] 读书笔记-壹百度:百度十年千倍的29条法则
- [45] 界面设计速成