我想我會把我的兩分錢投入到這個花盆中,討論一下我通常使用什么,無論是按原樣使用還是使用小的定制,用于我構建的PHP庫,而其他開發人員經常使用這些庫。

我將程序執行過程中可能出現的錯誤細分為兩類:那些是錯誤編程的結果,以及那些由于用戶錯誤或一些外部因素而發生的錯誤。對于前者,我將trigger_error與e_user_error結合使用,后者是一個異常,特別是一個包異常,然后由庫中的所有其他異常繼承。

開發錯誤的一個例子是在一個期望是字符串(V7之前)的參數中傳遞一個整數,或者訪問一個不存在的類的方法或屬性。(您可以在這里使用自己的開發人員想象力。)顯然,另一個開發人員不會在意錯誤是在“get”或“set”語句或其他一些神奇構造的內部深處生成的,而是希望知道錯誤的具體位置。讓我們面對現實吧……開發人員不想涉過回溯。

因此,我用來定位錯誤消息的方法很簡單:

function localize_error_msg($msg, $level) {

$level = (int)$level;

$backtrace = debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS, $level + 1)[$level];

return $msg . " in " . $backtrace['file'] . " on line " . $backtrace['line'];

}

我傳入的回溯級別取決于所使用的構造,通常是1或2,其余的都是不言而喻的。

為了防止“i n file on line n”的重復序列,我添加了這個錯誤處理程序:

set_error_handler(function($errno, $errstr, $errfile, $errline) {

if (preg_match('/on line \d+$/', $errstr) === 1)

die($errstr);

else return false;

}, E_USER_ERROR | E_USER_WARNING | E_USER_NOTICE);

同樣,我喜歡保持簡單。可以說,錯誤消息的本地化應該發生在處理程序中,但是之后,您必須能夠傳遞深度,這在處理程序中又增加了兩個層次,并且,在這之后會變得混亂。

快樂小徑!

總結

以上是生活随笔為你收集整理的php提示行号,在php中使用trigger_错误时如何获得正确的行号?的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。