首先,我意識到99%的PHP開發人員使用錯誤抑制操作符(我曾經是其中之一),所以我希望任何PHP開發人員都會對此持不同意見。
在您看來,使用@運算符來抑制PHP中的錯誤/警告是否有效,而您可能正在處理該錯誤?
簡短答覆:
不!
更長更正確的答案:
我不知道,因為我不知道一切,但到目前為止,我還沒有遇到這樣的情況,這是一個很好的解決方案。
為什么是壞的:
在我認為使用PHP大約7年的時間里,我已經看到了錯誤抑制操作符所造成的無休止的調試痛苦,而且從來沒有遇到過不可避免的情況。
問題是,您正在消除錯誤的代碼段當前可能只會導致所看到的錯誤;但是,當您更改被抑制的行所依賴的代碼或它運行的環境時,很有可能該行將嘗試輸出與您試圖忽略的錯誤完全不同的錯誤。那么,如何跟蹤沒有輸出的錯誤呢?歡迎來到調試地獄!
我花了很多年才意識到,我每隔幾個月就會因為被壓制的錯誤而浪費多少時間。大多數情況下(但不只是如此),這是在安裝第三方腳本/應用程序/庫之后,在開發人員環境中沒有錯誤,但不是我的,因為php或服務器配置不同,或者缺少依賴,通常會立即輸出錯誤,提醒問題所在,而不是開發人員添加了魔術@。
替代品(視情況和預期結果而定):
處理您所知道的實際錯誤,這樣如果一段代碼將導致某個錯誤,那么它就不會在特定情況下運行。但我想你知道這個部分,你只是擔心最終用戶會看到錯誤,這就是我現在要解決的問題。
對于常規錯誤,您可以設置一個錯誤處理程序,以便在您查看頁面時以您希望的方式輸出這些錯誤,但對最終用戶隱藏這些錯誤并將其記錄下來,這樣您就可以知道您的用戶觸發了哪些錯誤。
對于致命錯誤集display_errors
在php.ini中關閉(您的錯誤處理程序仍然被觸發)并啟用錯誤日志記錄。如果您有一個開發服務器和一個活動服務器(我建議這樣做),那么這個步驟在您的開發服務器上是不必要的,所以您仍然可以調試這些致命錯誤,而不必求助于查看錯誤日志文件。甚至有一個使用關機函數的技巧向錯誤處理程序發送大量致命錯誤。
總括而言:
請避開它。這可能有一個很好的理由,但我還沒有看到,所以直到那天,我才認為(@)錯誤抑制操作符是邪惡的。
你能讀懂我對錯誤控制操作符頁面的評論在PHP手冊中,如果你想要更多的信息