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

來源:互聯網
上載者:User

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在包含一個找不到的問題的時候, 會前後拋出倆個錯誤, 複製代碼 代碼如下:WARNING : 在PHP試圖開啟這個檔案的時候拋出.
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異常流程

注: 圖中有一處不嚴謹, 即在確定是否最後一個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.
PHP5 changelog:
Changed exception handling. Now each op_array doesn't contain ZEND_HANDLE_EXCEPTION opcode in the end. (Dmitry)

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.