深入理解PHP原理之异常机制
PHP的异常机制的原理是什么?
在PHP每一个可独立执行的op array最后的ZEND_HANDLE_EXCEPTION是用来干什么呢?
让我们从一个问题说起, 上周的时候, blue5tar提了一个问题:”对于下面的代码, onError明明执行了, 但是onException却没有执行, 为什么?”.
<?phpfunction onError($errCode, $errMesg, $errFile, $errLine) {
echo "Error Occurredn"; throw new Exception($errMesg);} function onException($e) {
echo $e->getMessage();} set_error_handler("onError"); set_exception_handler("onException");
/* 我从不会以我的名字命名文件, 所以这个文件不存在 */require("laruence.php");
运行结果:
Error OccurredPHP 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. 记录exception3. 记录下一条要执行的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异常流程
注: 图中有一处不严谨, 即在确定是否最后一个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.laruence.com/2010/08/03/1697.html
- Java常用工具类之自定义访问对象
- quartz定时任务,已过期的内容自动下线
- http请求,HttpClient,调用短信接口
- Java常用工具类之压缩解压
- Java常用工具类之MD5加密
- Java常用工具类之发送邮件
- Spring Boot入门
- IDEA使用
- JFinal极速开发框架使用笔记(二) 两个问题,一个发现
- JFinal极速开发框架使用笔记(三) 分析Model和ActiveRecord
- JFinal极速开发框架使用笔记(四) _JFinalDemoGenerator实体类生成及映射自动化
- Python语言做数据探索教程
- Java常用工具类之时间转换(注释乱码,全)
- Java常用工具类之RegexpUtils,正则表达式工具类
- php概述
- php教程
- php环境搭建
- PHP书写格式
- php变量
- php常量
- PHP注释
- php数组
- php字符串 string
- PHP整型 integer
- PHP浮点型 float
- php布尔型
- php数据类型之数组
- php数据类型之对象
- php数据类型之null
- php数据类型之间的转换
- php运算符
- php表达式
- PHP循环控制
- PHP流程控制
- php函数
- php全局变量
- PHP魔术变量
- php命名空间
- php 日期
- PHP包含文件
- php文件
- PHP 文件上传
- php Cookies
- php Sessions
- php email
- php安全email
- php错误处理
- PHP异常处理
- php过滤器
- PHP 高级过滤器
- php json
- php 表单
- PHP MySQL 简介
- PHP 连接 MySQL
- php创建数据库
- php 创建表
- php mysq 插入数据
- PHP MySQL 插入多条数据
- PHP MySQL 预处理语句
- php mysql 读取数据
- php mysql where
- PHP MySQL Order By
- PHP MySQL Update
- PHP MySQL Delete
- php ODBC
- Maven详细介绍
- RabbitMq 技术文档
- Kafka 技术文档
- Druid 数据库连接池监控配置(web项目)
- Druid 介绍及配置
- Kafka 分布式的,基于发布/订阅的消息系统
- Maven 打包涉及证书文件问题
- maven 安装alipay-sdk包到本地及远程仓库
- maven 基础 maven-shade-pluginMaven Scopepom.xml 样例
- zookeeper应用:屏障、队列、分布式锁
- Java AIO 异步IO应用实例
- Java NIO 同步非阻塞应用实例
- Spring Boot 示例项目
- Jetty 发布web服务
- Netty 异步的、事件驱动的网络应用程序框架和工具