快捷導(dǎo)航

深入理解PHP原理之異常機制

更新時間：2010年08月21日 21:38:13 作者：

在PHP每一個可獨立執(zhí)行的op array最后的ZEND_HANDLE_EXCEPTION是用來干什么呢?

PHP的異常機制的原理是什么?
在PHP每一個可獨立執(zhí)行的op array最后的ZEND_HANDLE_EXCEPTION是用來干什么呢?
讓我們從一個問題說起, 上周的時候, blue5tar提了一個問題:”對于下面的代碼, onError明明執(zhí)行了, 但是onException卻沒有執(zhí)行, 為什么?”.

復(fù)制代碼代碼如下:

 
<?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"); 

運行結(jié)果:

復(fù)制代碼代碼如下:

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

首先, 我們要知道, Require在包含一個找不到的問題的時候, 會前后拋出倆個錯誤,

復(fù)制代碼代碼如下:

 
WARNING : 在PHP試圖打開這個文件的時候拋出. 
E_COMPILE_ERROR : 從PHP打開文件的函數(shù)返回失敗以后拋出 

而我們知道, 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的同學(xué)都知道, 在PHP5.3以前, 每一個可獨立運行的op array(文件, 函數(shù), 方法)的最后一條opcode都是ZEND_HANDLE_EXCEPTION, 而這個opcode是做什么用的呢?
原來在PHP中, 當有異常被throw的時候, 會跳到每一個op array的最后一行, 來執(zhí)行這條ZEND_HANDLE_EXCEPTION, 偽碼如下:

復(fù)制代碼代碼如下:

 
void on_throw_exception(zval *exception TSRMLS_DC) { 
1. 判斷是否已經(jīng)有異常拋出 
2. 記錄exception 
3. 記錄下一條要執(zhí)行的op line的序號 
4. 下一條要執(zhí)行的op line序號 = 當前op array的最后一條 
} 

恩, 就和改寫ip寄存器一樣, 改寫下一條要執(zhí)行的op line的序號, 就改變了程序的流向, 這樣, 就會進入到了ZEND_HANDLE_EXCEPTION的處理邏輯中.
而在ZEND_HANDLE_EXCEPTION中, 會判斷這個異常是否在try catch中,

復(fù)制代碼代碼如下:

 
如果是 則把下一條要執(zhí)行的op line, 置為第一個catch的op line, 并繼續(xù)執(zhí)行. 
如果不是 則銷毀一些不需要的變量, 和opline, 然后直接結(jié)束執(zhí)行過程 

有的同學(xué)要問了:”那set_exception_handler設(shè)置的異常默認處理函數(shù)(user_exception_handler)什么時候起作用呢?”
恩, 是在執(zhí)行完成退出執(zhí)行LOOP以后才判斷是否有默認異常處理函數(shù), 如果有才調(diào)用:

復(fù)制代碼代碼如下:

 
//執(zhí)行 
zend_execute(EG(active_op_array) TSRMLS_CC); 
if (EG(exception)) { 
if (EG(user_exception_handler)) { 
調(diào)用用戶定義的默認異常處理函數(shù) 
} else { 
未捕獲的異常 
} 
} else { 
沒有異常 
} 
destroy_op_array(EG(active_op_array) TSRMLS_CC); 
efree(EG(active_op_array)); 

PHP異常流程

注: 圖中有一處不嚴謹, 即在確定是否最后一個catch塊的時候, 會同時判斷(is_a), 如果是才進入最后一個catch塊執(zhí)行.
而PHP在遇到Fatal Error的時候, 會直接zend_bailout, 而zend_bailout會導(dǎo)致程序流程直接跳過上面代碼段, 也可以理解為直接exit了(longjmp), 這就導(dǎo)致了user_exception_handler沒有機會發(fā)生作用.
了解到這些, 我想文章開頭的問題的為什么? 也就很清晰了吧?
最后, 關(guān)于ZEND_HANDLE_EXCEPTION, 也許有同學(xué)會有疑問: 如果是這樣, 那為什么每一個可獨立執(zhí)行的op array最后都有這個ZEND_HANDLE_EXCEPTION呢? 最簡單的, 如果一個函數(shù)中不會throw, 那么這個opcode 是明顯不需要的啊? 嘿嘿, 你很聰明, PHP 5.3開始, 已經(jīng)按照你的想法調(diào)整了.. 只有在throw時刻, 才會動態(tài)的生成ZEND_HANDLE_EXCEPTION opline.
PHP5 changelog:
Changed exception handling. Now each op_array doesn't contain ZEND_HANDLE_EXCEPTION opcode in the end. (Dmitry)

您可能感興趣的文章: