更新！

使用下面的答案，我完成了一個error handler的處理，它處理E_ERROR | E_PARSE | E_WARNING | E_NOTICE，並且在致命的時候會殺死腳本！ :-)

2010-12-14 tarnfeld

引述手冊：

以下錯誤類型不能與用戶定義的函數來處理：E_ERROR，E_PARSE，E_CORE_ERROR，E_CORE_WARNING，E_COMPILE_ERROR，E_COMPILE_WARNING，大部分E_STRICT在調用set_error_handler()的文件中引發。

這意味着fatals不能被捕獲和處理。可以設置一個額外的處理程序，在腳本退出時運行，例如， register_shutdown_function。

在該處理程序中，使用error_get_last並檢查它是否爲致命錯誤。這將不允許您繼續執行腳本執行。該腳本將結束，但你可以做任何清理或日誌記錄（通常情況下，無論如何都會將致命錯誤記錄到error.log）或其他內容。

有一個user-supplied example in the comments below set_error_handler

register_shutdown_function('shutdownFunction'); 
function shutDownFunction() { 
    $error = error_get_last(); 
    if ($error['type'] == 1) { 
     //do your stuff  
    } 
}

但是請注意，這將仍然只捕獲某些額外的運行時錯誤。

來源

2010-12-14 11:46:09 Gordon

甜。從來沒有想過使用shutdown_function。 – Mchl 2010-12-14 12:02:10

不，捕捉致命錯誤和解析錯誤是不可能的。解析錯誤，因爲它們是在編譯腳本之前引發的。致命錯誤，因爲它們是...致命的（即腳本遇到它們後無法繼續運行）

來源

2010-12-14 11:40:51 Mchl

這很煩人。所以保持自己更新生產網站上的錯誤是不可能的！如何蹩腳:( – tarnfeld 2010-12-14 11:42:32

你的產品代碼應該永遠不會有解析錯誤（來吧！這是一個體面的IDE可以幫助你）還有一些方法可以避免致命錯誤（例如，在嘗試實例化對象之前檢查class_exists（）這個類） – Mchl 2010-12-14 11:44:58

是的，我知道，沒有那麼多的解析錯誤，但我不希望網站只是因爲內存不足而崩潰......輸出一些快速文本給用戶將是一個不錯的選擇 – tarnfeld 2010-12-14 11:48:47

您可能會留意error_log。在Ubuntu這個位於/var/log/apache2/error_log

來源

2010-12-14 11:44:10 Quamis

如果您想要捕捉致命錯誤（包括解析錯誤），最好的解決方案是在php.ini文件中設置error_logging，例如

display_errors = Off 
log_errors = On 
ignore_repeated_errors = Off 
ignore_repeated_source = Off

來源

2010-12-14 11:48:11 symcbean

所謂的「致命錯誤」可能是php中最令人討厭的錯誤。我們可以做的最好的事情就是說服「php羣組」通過投票支持http://bugs.php.net/bug.php?id=28331來識別這個bug。

只要這不是固定的，我們註定要使用關閉錯誤處理程序或自動加載等骯髒的黑客。

來源

2010-12-14 12:04:31 user187291

管理PHP錯誤

更新！

回答

相關問題