有沒有解決「解析死亡錯誤」的方法？

Question

我很確定我不只是一個已經注意到PHP的簡單解析錯誤，如果存在於非常嵌套的場景中（例如，引用另一個對象實例的對象實例，該對象實例引用具有非常小的另一個對象實例解析錯誤，所有這些都是自動加載的）可以使PHP永久掛起，而不是報告解析錯誤，並像往常一樣停止執行 - 我已經看到了很多次，並且在非常不同的代碼庫中，始終使用正確的error_reporting設置。

有沒有辦法解決它？也就是說，它可以強制顯示解析錯誤報告，因爲它應該以某種方式？

爲了記錄，我100％確定這些掛起是由於PHP沒有正確處理解析錯誤而導致的，因爲我已經多次調試此行爲;我問的原因是因爲當這些掛起事件發生時，基本上都是在黑暗中，甚至無法分辨PHP是否有趣，或者代碼中確實存在故障循環 - 這需要時間進行調試，可能會花費時間如果你知道PHP會報告解析錯誤。

Answer 1

原來的罪魁禍首是xdebug.collect_params，該文檔非常正確地建議禁用。某些錯誤只是在調用堆棧跟蹤的參數中生成大量數據，這些數據用於將collect_params設置爲4的xdebug並使xdebug和擴展PHP掛起，即使我有一個自定義的異常處理程序，從xdebug中檢索堆棧跟蹤，但顯然xdebug無論如何收集這些數據。

這很難調試，因爲：a）不容易複製b）使用xdebug進行分析並沒有幫助c）使用xdebug + dbgp單步執行代碼沒有幫助d）幾乎沒有任何痕跡（沒有雙關語意思）是非非常ocasionally錯誤日誌記錄到php error_log文件和e）與自定義異常處理程序它不明顯懷疑xdebug，因爲我沒有涉及它在處理異常的過程中，或所以我認爲。

所以沒有死亡分析錯誤這樣的事情，我學會了永遠不要認爲它不是我的錯:)希望這個答案至少可以幫助其他人。

Answer 2

正如註釋中部分提到的那樣，error_reporting(E_ALL)可以幫助顯示所有錯誤。您可能還必須使用ini_set，並使display_errors的值爲on。

就我個人而言，我認爲你的問題不是很清楚，你應該改進格式並使其更容易理解。

更新：您正在運行代碼的服務器/計算機似乎非常慢。實際上不應該發生「徘徊」。或者你可以用更詳細的描述來描述它嗎？

另外，您可能會陷入無限或接近無限循環。仔細檢查您的代碼，因爲除非您發佈了所有代碼，否則這是我們可以幫助您的限制。

UPDATE 2：看起來，您可能錯誤地打了一個對象的名稱，當你試圖調用它。否則，可能是你沒有正確聲明你的對象。

最有可能的一個或另一個。