你知道PHP中Exception，Error Handler的這些細節嗎？

前言

最近項目中有一個功能需要實現:

調試模式下, 將所有錯誤提前輸出, 再輸出頁面內容.

為實現上述功能, 需使用到, 相關方法, 發現有許多坑, 故寫此文與大家分享.

主要函數

此篇文章重點關注以下幾個函數

這有什麼難的?

哈~ 如果您現在有標題中的感慨, 那麼也請關注以下本文中將重點講述的問題列表:

與 有什麼聯繫?

與 綁定的什麼時候才會啟動? 它們有什麼聯繫?

通常跟有關係么?

上述問題描述模糊, 因此答案也可能千人千面.

因此, 本文只給出自己的答案與大家分享, 如有問題或不同的見解, 期待與您溝通.

如果以上問題, 並不能引起您的興趣, 或者您已理解透徹了, 就可以自行右上角小紅叉啦~

解疑:1. 與 有什麼聯繫?

link: php.net - error_reporting()

link: php.net - error_get_last()

大家應該再熟悉不過了, 因此不再贅述.

獲取最後發生的錯誤.

通常用來獲取PHP運行過程中的錯誤().

這兩個函數在字面上關聯性並不強, 但請觀察以下代碼及輸出

雖然說明了獲取最後發生的錯誤, 實際上也是如此. 但卻沒有說明, 被忽略掉的錯誤是否有可能被獲取到, 因此, 當我們使用時需要注意我平時忽略掉的錯誤, 如:

2. 與 綁定的什麼時候才會啟動? 它們有什麼聯繫?

link: php.net - set_error_handler()

link: php.net - set_exception_handler()

設置用戶自定義的錯誤處理函數.

通常在PHP腳本運行過程中, 出現一些非中斷性錯誤時觸發.

我們會用這個來記錄錯誤日誌或直接輸出等操作.

注意:

: 標準的錯誤處理依然會被執行(標準錯誤處理根據 display_errors = true/false 決定是否輸出到)

參數大多設定為, 但建議設定為, 具體哪些錯誤需要被處理, 哪些不需要, 在內進行判斷明顯更加靈活.

以下級別的錯誤不能由用戶定義的函數來處理： E_ERROR、 E_PARSE、 E_CORE_ERROR、 E_CORE_WARNING、 E_COMPILE_ERROR、 E_COMPILE_WARNING，和在 調用 set_error_handler() 函數所在文件中產生的大多數 E_STRICT

被觸發後, 並不會中斷PHP運行.

注意的返回值:

設置用戶自定義的異常處理函數

設置默認的異常處理程序，用於沒有用 try/catch 塊來捕獲的異常。 在 exception_handler 調用後異常會中止。

注意:

注意點中2, 3項輕描淡寫了一下之間的不同卻透露出重要的消息(坑..)

中, 不再只接受了, 並且接收了錯誤.

link: php.net - PHP7 Errors列表

調用後異常會中止(腳本終止).

, 的並不相同.

:

:

自 PHP 7 以來，大多數錯誤拋出 Error 異常，也能被捕獲。 Error 和 Exception 都實現了 Throwable 介面。

因此, 與 之間的關係也迎刃而解:

:

: 負責非中斷行錯誤.

: 負責沒有被catch的異常(會中斷).

等: 並不會被兩者管理, 正常輸出到屏幕上(弊端).

:

: 負責非中斷行錯誤.

: 負責沒有被catch的異常, (會中斷)

等: 由管理.

3. 通常跟Exception/Error有關係么?

link: php.net - register_shutdown_function()

註冊一個 callback ，它會在腳本執行完成或者 exit() 後被調用。

根據說明可以得出結論, 它與完全沒關係.

提出這個問題, 主要是因為, 在中並沒有明確的接收地點, 所以我們通常配合來接收

然而隨著的到來, 已經可以被捕捉了, 再通過就多餘了. 中更多的是一些版本冗餘的工作.

栗子

前言中的需求: 調試模式下, 將所有錯誤提前輸出, 再輸出頁面內容.

以下是demo, 省去了環境判斷(debug環境), 大家可以根據下面這段代碼, 了解本文中所說的各種的觸發和調用情況.

點擊展開全文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！