PHP 程序員也要學會使用“異常”
更新時間:2009年06月16日 22:37:57 作者:
“PHP程序員,特別是從php4,甚至是PHP3中成長起來的程序員,很多都不習慣使用拋出異常這種錯誤處理方式。雖然php5引入了異常處理機制,但是很多php程序員還是沒有真正的掌握并使用它。
網站完全開放的特性,決定了網站比任何傳統軟件都更希望做到“系統看起來永遠都是能夠正常工作的”,所以采用正確的程序錯誤處理方式尤為重要。理論上來說,如果設計足夠完美,開發(fā)人員足夠謹慎,程序出現錯誤的可能為0.
但事實恰恰相反,復雜的業(yè)務邏輯,不同的硬件環(huán)境,或者不可信任的用戶輸入,都可能導致程序出錯,服務當機。所以在稍微有點復雜的系統中,有個完善的錯誤機制是必須的。
在php5之前,因為缺乏對異常的支持。在做復雜的開發(fā)時,常常采取比較原始的“處理錯誤數值+記錄log”的處理形式。
如:
function getResult($a,$b)
{
.......
if fatal error occur
return "error_type1";
.....
}
$result = getResult($a,$b);//理論上,getResult函數總能正確的返回$result
if($result=='error_type1')//但在一些特殊情況.$result無法正常取得
{
writeLog('result is empty!');//記錄下log
die();//或者其他更“友好的”處理方式
}
理論上,通過“處理錯誤數值+記錄log”的方式也可以達到我們的目標(事實上確實如此,在php3,php4的時候,已經出現了很多成功且足夠復雜的系統,他們甚至考慮到所有的情況,因此不需要記錄任何log)。但技術總要向前發(fā)展的,更何況,決大多數的開發(fā)人員并不具備牛人的嚴謹到滴水不漏的思維,所以我們還是不得不認真思考“如何處理程序錯誤”的問題。
上面的“錯誤處理+記錄log”的方式,存在如下弊端:
1 如果錯誤情況太多,那相應的錯誤處理代碼需要增加很多,這非常損害程序的可讀性。你的程序看起來是“斷斷續(xù)續(xù)的”。
2 如果程序的邏輯很復雜(比如程序的函數調用非常復雜,如在 getResult2()函數 中調用 getResult() 的情況,甚至更復雜的多級嵌套的情況),那錯誤數值的傳遞處理會讓你疲于奔命。因為為了確保錯誤能夠得到有效的處理,你必須保證: 以無損耗的方式傳遞錯誤數值。
所以,改變這種原始的錯誤處理方式吧。引入異常處理機制,你會發(fā)現可喜的變化:
1 代碼可讀性大大增強。開發(fā)程序時邏輯思維變得很連貫,在“可疑的”地方,你只要拋出個異常就可以了。至于怎么處理,完全可以等到后面再去補充。當然,對于程序的讀者,也不會覺得有被打斷的感覺。
2 再也不需要考慮“錯誤數值如何無損耗的進行傳遞”這種費力又不怎么討好的問題了。因為異常向上傳遞的特性,你的函數嵌套個2層,3層,再多層都沒有問題。你只需要在外層有捕獲異常的操作就可以了。
3 異??梢宰杂傻亩ㄖ?,你可以按照功能對異常進行分類,更好的管理各種程序錯誤。同時對于你也可以更靈活的定制異常的處理方式。比如,在異常類里面實現記錄log的功能等。
當然,是否使用異常要根據需求而定。php的一大特性就是部署快,如果是很小的項目,邏輯很簡單,那使用一般的錯誤數值處理方式也許能夠更快的部署。
但事實恰恰相反,復雜的業(yè)務邏輯,不同的硬件環(huán)境,或者不可信任的用戶輸入,都可能導致程序出錯,服務當機。所以在稍微有點復雜的系統中,有個完善的錯誤機制是必須的。
在php5之前,因為缺乏對異常的支持。在做復雜的開發(fā)時,常常采取比較原始的“處理錯誤數值+記錄log”的處理形式。
如:
復制代碼 代碼如下:
function getResult($a,$b)
{
.......
if fatal error occur
return "error_type1";
.....
}
$result = getResult($a,$b);//理論上,getResult函數總能正確的返回$result
if($result=='error_type1')//但在一些特殊情況.$result無法正常取得
{
writeLog('result is empty!');//記錄下log
die();//或者其他更“友好的”處理方式
}
理論上,通過“處理錯誤數值+記錄log”的方式也可以達到我們的目標(事實上確實如此,在php3,php4的時候,已經出現了很多成功且足夠復雜的系統,他們甚至考慮到所有的情況,因此不需要記錄任何log)。但技術總要向前發(fā)展的,更何況,決大多數的開發(fā)人員并不具備牛人的嚴謹到滴水不漏的思維,所以我們還是不得不認真思考“如何處理程序錯誤”的問題。
上面的“錯誤處理+記錄log”的方式,存在如下弊端:
1 如果錯誤情況太多,那相應的錯誤處理代碼需要增加很多,這非常損害程序的可讀性。你的程序看起來是“斷斷續(xù)續(xù)的”。
2 如果程序的邏輯很復雜(比如程序的函數調用非常復雜,如在 getResult2()函數 中調用 getResult() 的情況,甚至更復雜的多級嵌套的情況),那錯誤數值的傳遞處理會讓你疲于奔命。因為為了確保錯誤能夠得到有效的處理,你必須保證: 以無損耗的方式傳遞錯誤數值。
所以,改變這種原始的錯誤處理方式吧。引入異常處理機制,你會發(fā)現可喜的變化:
1 代碼可讀性大大增強。開發(fā)程序時邏輯思維變得很連貫,在“可疑的”地方,你只要拋出個異常就可以了。至于怎么處理,完全可以等到后面再去補充。當然,對于程序的讀者,也不會覺得有被打斷的感覺。
2 再也不需要考慮“錯誤數值如何無損耗的進行傳遞”這種費力又不怎么討好的問題了。因為異常向上傳遞的特性,你的函數嵌套個2層,3層,再多層都沒有問題。你只需要在外層有捕獲異常的操作就可以了。
3 異??梢宰杂傻亩ㄖ?,你可以按照功能對異常進行分類,更好的管理各種程序錯誤。同時對于你也可以更靈活的定制異常的處理方式。比如,在異常類里面實現記錄log的功能等。
當然,是否使用異常要根據需求而定。php的一大特性就是部署快,如果是很小的項目,邏輯很簡單,那使用一般的錯誤數值處理方式也許能夠更快的部署。
相關文章
PHP編程計算兩個時間段是否有交集的實現方法(不算邊界重疊)
這篇文章主要介紹了PHP編程計算兩個時間段是否有交集的實現方法,結合具體實例形式對比分析了php時間段的轉換、比較等相關操作技巧,需要的朋友可以參考下2017-05-05PHP中調試函數debug_backtrace的使用示例代碼
debug_backtrace() 是一個很低調的函數,很少有人注意過它,這篇文章主要給大家介紹了關于PHP中調試函數debug_backtrace的使用方法,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,感興趣的朋友們隨著小編來一起學習學習吧。2017-09-09php計算數組相同值出現次數的代碼(array_count_values)
這篇文章主要介紹了php計算數組相同值出現次數的代碼,需要的朋友可以參考下2015-01-01PHP+Apache環(huán)境中如何隱藏Apache版本
以PHP+Apache服務器環(huán)境為例,給大家講解如何能夠隱藏Apache的版本號以及具體做法。2017-11-11