程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> 網頁編程 >> PHP編程 >> PHP綜合 >> 詳解PHP異常機制的流程及原理

詳解PHP異常機制的流程及原理

編輯: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的最後一條    
  6. }  

  就和改寫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異常流程

  

 

  注: 圖中有一處不嚴謹, 即在確定是否最後一個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.

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved