PHP原理之異常機(jī)制深入分析
更新時(shí)間：2010年08月08日 18:18:14 作者：
在PHP每一個(gè)可獨(dú)立執(zhí)行的op array最后的ZEND_HANDLE_EXCEPTION是用來(lái)干什么呢?
PHP的異常機(jī)制的原理是什么?
在PHP每一個(gè)可獨(dú)立執(zhí)行的op array最后的ZEND_HANDLE_EXCEPTION是用來(lái)干什么呢?
讓我們從一個(gè)問(wèn)題說(shuō)起, 上周的時(shí)候, blue5tar提了一個(gè)問(wèn)題:”對(duì)于下面的代碼, onError明明執(zhí)行了, 但是onException卻沒(méi)有執(zhí)行, 為什么?”.
<?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");
/* 我從不會(huì)以我的名字命名文件, 所以這個(gè)文件不存在 */
require("laruence.php");
運(yùn)行結(jié)果:
Error Occurred
PHP Fatal error: main(): Failed opening required 'laruence.php
首先, 我們要知道, Require在包含一個(gè)找不到的問(wèn)題的時(shí)候, 會(huì)前后拋出倆個(gè)錯(cuò)誤,
1. WARNING : 在PHP試圖打開(kāi)這個(gè)文件的時(shí)候拋出.
2. E_COMPILE_ERROR : 從PHP打開(kāi)文件的函數(shù)返回失敗以后拋出
而我們知道, set_error_handler是不能捕獲E_COMPILE_ERROR錯(cuò)誤的:
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中, 只能捕獲到第一個(gè)WARNING錯(cuò)誤, 而在onError中拋出的異常, 為什么沒(méi)有被默認(rèn)exception_handler捕獲呢?
這就要說(shuō)說(shuō)PHP的異常機(jī)制了.
了解opcode(深入理解PHP原理之Opcodes的同學(xué)都知道, 在PHP5.3以前, 每一個(gè)可獨(dú)立運(yùn)行的op array(文件, 函數(shù), 方法)的最后一條opcode都是ZEND_HANDLE_EXCEPTION, 而這個(gè)opcode是做什么用的呢?
原來(lái)在PHP中, 當(dāng)有異常被throw的時(shí)候, 會(huì)跳到每一個(gè)op array的最后一行, 來(lái)執(zhí)行這條ZEND_HANDLE_EXCEPTION, 偽碼如下:
void on_throw_exception(zval *exception TSRMLS_DC) {
1. 判斷是否已經(jīng)有異常拋出
2. 記錄exception
3. 記錄下一條要執(zhí)行的op line的序號(hào)
4. 下一條要執(zhí)行的op line序號(hào) = 當(dāng)前op array的最后一條
}
恩, 就和改寫(xiě)ip寄存器一樣, 改寫(xiě)下一條要執(zhí)行的op line的序號(hào), 就改變了程序的流向, 這樣, 就會(huì)進(jìn)入到了ZEND_HANDLE_EXCEPTION的處理邏輯中.
而在ZEND_HANDLE_EXCEPTION中, 會(huì)判斷這個(gè)異常是否在try catch中,
如果是 則把下一條要執(zhí)行的op line, 置為第一個(gè)catch的op line, 并繼續(xù)執(zhí)行.
如果不是 則銷(xiāo)毀一些不需要的變量, 和opline, 然后直接結(jié)束執(zhí)行過(guò)程
有的同學(xué)要問(wèn)了:”那set_exception_handler設(shè)置的異常默認(rèn)處理函數(shù)(user_exception_handler)什么時(shí)候起作用呢?”
恩, 是在執(zhí)行完成退出執(zhí)行LOOP以后才判斷是否有默認(rèn)異常處理函數(shù), 如果有才調(diào)用:
//執(zhí)行
zend_execute(EG(active_op_array) TSRMLS_CC);
if (EG(exception)) {
if (EG(user_exception_handler)) {
調(diào)用用戶(hù)定義的默認(rèn)異常處理函數(shù)
} else {
未捕獲的異常
}
} else {
沒(méi)有異常
}
destroy_op_array(EG(active_op_array) TSRMLS_CC);
efree(EG(active_op_array));
PHP異常流程
而PHP在遇到Fatal Error的時(shí)候, 會(huì)直接zend_bailout, 而zend_bailout會(huì)導(dǎo)致程序流程直接跳過(guò)上面代碼段, 也可以理解為直接exit了(longjmp), 這就導(dǎo)致了user_exception_handler沒(méi)有機(jī)會(huì)發(fā)生作用.
了解到這些, 我想文章開(kāi)頭的問(wèn)題的為什么? 也就很清晰了吧?
最后, 關(guān)于ZEND_HANDLE_EXCEPTION, 也許有同學(xué)會(huì)有疑問(wèn): 如果是這樣, 那為什么每一個(gè)可獨(dú)立執(zhí)行的op array最后都有這個(gè)ZEND_HANDLE_EXCEPTION呢? 最簡(jiǎn)單的, 如果一個(gè)函數(shù)中不會(huì)throw, 那么這個(gè)opcode 是明顯不需要的啊? 嘿嘿, 你很聰明, PHP 5.3開(kāi)始, 已經(jīng)按照你的想法調(diào)整了.. 只有在throw時(shí)刻, 才會(huì)動(dòng)態(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)
在PHP每一個(gè)可獨(dú)立執(zhí)行的op array最后的ZEND_HANDLE_EXCEPTION是用來(lái)干什么呢?
讓我們從一個(gè)問(wèn)題說(shuō)起, 上周的時(shí)候, blue5tar提了一個(gè)問(wèn)題:”對(duì)于下面的代碼, onError明明執(zhí)行了, 但是onException卻沒(méi)有執(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");
/* 我從不會(huì)以我的名字命名文件, 所以這個(gè)文件不存在 */
require("laruence.php");
運(yùn)行結(jié)果:
復(fù)制代碼 代碼如下:
Error Occurred
PHP Fatal error: main(): Failed opening required 'laruence.php
首先, 我們要知道, Require在包含一個(gè)找不到的問(wèn)題的時(shí)候, 會(huì)前后拋出倆個(gè)錯(cuò)誤,
復(fù)制代碼 代碼如下:
1. WARNING : 在PHP試圖打開(kāi)這個(gè)文件的時(shí)候拋出.
2. E_COMPILE_ERROR : 從PHP打開(kāi)文件的函數(shù)返回失敗以后拋出
而我們知道, set_error_handler是不能捕獲E_COMPILE_ERROR錯(cuò)誤的:
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中, 只能捕獲到第一個(gè)WARNING錯(cuò)誤, 而在onError中拋出的異常, 為什么沒(méi)有被默認(rèn)exception_handler捕獲呢?
這就要說(shuō)說(shuō)PHP的異常機(jī)制了.
了解opcode(深入理解PHP原理之Opcodes的同學(xué)都知道, 在PHP5.3以前, 每一個(gè)可獨(dú)立運(yùn)行的op array(文件, 函數(shù), 方法)的最后一條opcode都是ZEND_HANDLE_EXCEPTION, 而這個(gè)opcode是做什么用的呢?
原來(lái)在PHP中, 當(dāng)有異常被throw的時(shí)候, 會(huì)跳到每一個(gè)op array的最后一行, 來(lái)執(zhí)行這條ZEND_HANDLE_EXCEPTION, 偽碼如下:
復(fù)制代碼 代碼如下:
void on_throw_exception(zval *exception TSRMLS_DC) {
1. 判斷是否已經(jīng)有異常拋出
2. 記錄exception
3. 記錄下一條要執(zhí)行的op line的序號(hào)
4. 下一條要執(zhí)行的op line序號(hào) = 當(dāng)前op array的最后一條
}
恩, 就和改寫(xiě)ip寄存器一樣, 改寫(xiě)下一條要執(zhí)行的op line的序號(hào), 就改變了程序的流向, 這樣, 就會(huì)進(jìn)入到了ZEND_HANDLE_EXCEPTION的處理邏輯中.
而在ZEND_HANDLE_EXCEPTION中, 會(huì)判斷這個(gè)異常是否在try catch中,
復(fù)制代碼 代碼如下:
如果是 則把下一條要執(zhí)行的op line, 置為第一個(gè)catch的op line, 并繼續(xù)執(zhí)行.
如果不是 則銷(xiāo)毀一些不需要的變量, 和opline, 然后直接結(jié)束執(zhí)行過(guò)程
有的同學(xué)要問(wèn)了:”那set_exception_handler設(shè)置的異常默認(rèn)處理函數(shù)(user_exception_handler)什么時(shí)候起作用呢?”
恩, 是在執(zhí)行完成退出執(zhí)行LOOP以后才判斷是否有默認(rèn)異常處理函數(shù), 如果有才調(diào)用:
復(fù)制代碼 代碼如下:
//執(zhí)行
zend_execute(EG(active_op_array) TSRMLS_CC);
if (EG(exception)) {
if (EG(user_exception_handler)) {
調(diào)用用戶(hù)定義的默認(rèn)異常處理函數(shù)
} else {
未捕獲的異常
}
} else {
沒(méi)有異常
}
destroy_op_array(EG(active_op_array) TSRMLS_CC);
efree(EG(active_op_array));
PHP異常流程
而PHP在遇到Fatal Error的時(shí)候, 會(huì)直接zend_bailout, 而zend_bailout會(huì)導(dǎo)致程序流程直接跳過(guò)上面代碼段, 也可以理解為直接exit了(longjmp), 這就導(dǎo)致了user_exception_handler沒(méi)有機(jī)會(huì)發(fā)生作用.
了解到這些, 我想文章開(kāi)頭的問(wèn)題的為什么? 也就很清晰了吧?
最后, 關(guān)于ZEND_HANDLE_EXCEPTION, 也許有同學(xué)會(huì)有疑問(wèn): 如果是這樣, 那為什么每一個(gè)可獨(dú)立執(zhí)行的op array最后都有這個(gè)ZEND_HANDLE_EXCEPTION呢? 最簡(jiǎn)單的, 如果一個(gè)函數(shù)中不會(huì)throw, 那么這個(gè)opcode 是明顯不需要的啊? 嘿嘿, 你很聰明, PHP 5.3開(kāi)始, 已經(jīng)按照你的想法調(diào)整了.. 只有在throw時(shí)刻, 才會(huì)動(dòng)態(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)
相關(guān)文章
php 一元分詞算法2009-11-11
實(shí)戰(zhàn)mysql導(dǎo)出中文亂碼及phpmyadmin導(dǎo)入中文亂碼的解決方法
因?yàn)橐驯緳C(jī)的gbk編碼的mysql數(shù)據(jù)庫(kù)導(dǎo)入到虛擬主機(jī)去，服務(wù)商只提供了phpmyadmin供你導(dǎo)入導(dǎo)出。2010-06-06
php實(shí)現(xiàn)的支持imagemagick及gd庫(kù)兩種處理的縮略圖生成類(lèi)
這篇文章主要介紹了php實(shí)現(xiàn)的支持imagemagick及gd庫(kù)兩種處理的縮略圖生成類(lèi),包含了用法的詳細(xì)描述,非常實(shí)用,需要的朋友可以參考下2014-09-09
PHP錯(cuò)誤抑制符(@)導(dǎo)致引用傳參失敗Bug的分析
今天cici網(wǎng)友發(fā)來(lái)一個(gè)問(wèn)題, 說(shuō)是在函數(shù)調(diào)用參數(shù)前面使用錯(cuò)誤抑制符號(hào)(@)的時(shí)候, 貌似引用傳參就失效了. 他想讓我?guī)退獯馂槭裁?2011-05-05
PHP正則表達(dá)式 /i, /is, /s, /isU等介紹
PHP正則表達(dá)式 /i, /is, /s, /isU等，都代表著什么意思，你知道嗎？下面為大家詳細(xì)介紹下2014-10-10
PHP入門(mén)教程之會(huì)話(huà)控制技巧(cookie與session)
這篇文章主要介紹了PHP入門(mén)教程之會(huì)話(huà)控制技巧,結(jié)合實(shí)例形式分析了cookie與session的具體使用方法與相關(guān)注意事項(xiàng),需要的朋友可以參考下2016-09-09
2009-12-12
解析阿里云ubuntu12.04環(huán)境下配置Apache+PHP+PHPmyadmin+MYsql
本篇文章是對(duì)在阿里云ubuntu12.04環(huán)境下配置Apache+PHP+PHPmyadmin+MYsql的具體操作流程進(jìn)行了詳細(xì)的分析介紹，需要的朋友參考下2013-06-06
這篇文章主要介紹了PHP驗(yàn)證碼無(wú)法顯示的原因及解決辦法的相關(guān)資料,這里說(shuō)明了如何出現(xiàn)無(wú)法顯示的原因及相應(yīng)的解決辦法，需要的朋友可以參考下2017-08-08
php實(shí)現(xiàn)JWT驗(yàn)證的實(shí)例教程
這篇文章主要給大家介紹了關(guān)于php實(shí)現(xiàn)JWT驗(yàn)證的相關(guān)資料，文中通過(guò)示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來(lái)一起學(xué)習(xí)學(xué)習(xí)吧2020-11-11