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异常流程
而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.
php5 changelog:
changed exception handling. now each op_array doesn't contain zend_handle_exception opcode in the end. (dmitry)
评论列表:
发布于 3天前回复该评论
发布于 3天前回复该评论
发布于 3天前回复该评论
发布于 3天前回复该评论
发布于 2天前回复该评论
发布于 2天前回复该评论
发布于 2天前回复该评论
-
.jpg)
henbucuo
- 写的很不错，学到了！
显示更多评论发布于 2天前回复该评论