解读PHP异常机制的流程及原理

开发 后端
PHP中大多数函数或内置类库如果产生错误,不会抛出异常。异常机制是在PHP 5之后添加的,本文将结合实例,向您介绍PHP异常机制的流程及原理。

PHP的异常机制的原理是什么?在PHP每一个可独立执行的op array***的ZEND_HANDLE_EXCEPTION是用来干什么呢?让我们从一个问题说起。

对于一下代码,onError明明执行了, 但是onException却没有执行, 为什么呢?

  1. <?php 
  2. function onError($errCode, $errMesg, $errFile, $errLine) {      
  3. echo "Error Occurred\n";      
  4. throw new Exception($errMesg);  
  5. }   
  6. function onException($e) {      
  7. echo $e->getMessage();  
  8. }   
  9. set_error_handler("onError");   
  10. set_exception_handler("onException");   
  11. /* 我从不会以我的名字命名文件, 所以这个文件不存在 */  
  12. require("laruence.php"); 

运行结果:

  1. Error Occurred  
  2. PHP Fatal error: main(): Failed opening required 'laruence.php 

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

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

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

而我们知道, set_error_handler是不能捕获E_COMPILE_ERROR错误的。所以, 在onError中, 只能捕获到***个WARNING错误, 而在onError中抛出的异常, 为什么没有被默认exception_handler捕获呢?这就要说说PHP的异常机制了.

了解opcode的同学都知道, 在PHP5.3以前, 每一个可独立运行的op array(文件, 函数, 方法)的***一条opcode都是ZEND_HANDLE_EXCEPTION, 而这个opcode是做什么用的呢?

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

  1. void on_throw_exception(zval *exception TSRMLS_DC) {  
  2. 1. 判断是否已经有异常抛出  
  3. 2. 记录exception  
  4. 3. 记录下一条要执行的op line的序号  
  5. 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以后才判断是否有默认异常处理函数, 如果有才调用:

  1. //执行  
  2. zend_execute(EG(active_op_array) TSRMLS_CC);  
  3. if (EG(exception)) {       
  4.    if (EG(user_exception_handler)) {            
  5.        调用用户定义的默认异常处理函数       
  6.     }   
  7.     else {            
  8.        未捕获的异常       
  9.     }  
  10. }   
  11. else {       
  12. 没有异常  
  13.       }  
  14. destroy_op_array(EG(active_op_array) TSRMLS_CC);  
  15. efree(EG(active_op_array)); 

PHP异常流程

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

【编辑推荐】

  1. 探秘PHP 5的对象重载技术
  2. 深入理解PHP中的匿名函数
  3. 大型Web应用运行时 PHP负载均衡指南
  4. 不常见却非常有用的PHP函数
  5. PHP开发不能违背的安全规则
责任编辑:王晓东 来源: laruence.com
相关推荐

2009-12-11 10:29:03

PHP插件机制

2009-12-11 10:52:37

PHP运行机制

2015-11-16 11:17:30

PHP底层运行机制原理

2020-05-15 08:10:14

HTTP3应用协议

2024-03-11 00:39:40

2010-10-09 16:40:52

2017-05-31 13:16:35

PHP运行机制原理解析

2009-07-18 13:26:48

2024-09-06 09:37:45

WebApp类加载器Web 应用

2009-12-07 19:48:10

PHP单元素设计模式

2023-06-15 14:09:00

解析器Servlet容器

2009-12-07 15:34:18

PHP类的封装

2009-12-01 19:28:16

PHP模板

2022-08-30 09:01:11

浏览器渲染前端

2016-09-02 12:34:52

2023-02-23 08:15:33

Spring异常处理机制

2018-06-05 08:58:38

Docker存储容器

2018-11-30 09:03:55

HTTP缓存Web

2009-11-26 09:06:35

PHP递归数组

2009-12-07 18:57:17

PHP读取Cookie
点赞
收藏

51CTO技术栈公众号