|
|
但事實(shí)恰恰相反，復(fù)雜的業(yè)務(wù)邏輯，不同的硬件環(huán)境，或者不可信任的用戶輸入，都可能導(dǎo)致程序出錯(cuò)，服務(wù)當(dāng)機(jī)。所以在稍微有點(diǎn)復(fù)雜的系統(tǒng)中，有個(gè)完善的錯(cuò)誤機(jī)制是必須的。
在php5之前，因?yàn)槿狈?duì)異常的支持。在做復(fù)雜的開發(fā)時(shí)，常常采取比較原始的“處理錯(cuò)誤數(shù)值+記錄log”的處理形式。
如：
復(fù)制代碼 代碼如下:
function getResult($a,$b)
{
.......
if fatal error occur
return "error_type1";
.....
}
$result = getResult($a,$b);//理論上，getResult函數(shù)總能正確的返回$result
if($result=='error_type1')//但在一些特殊情況.$result無法正常取得
{
writeLog('result is empty!');//記錄下log
die();//或者其他更“友好的”處理方式
}
理論上，通過“處理錯(cuò)誤數(shù)值+記錄log”的方式也可以達(dá)到我們的目標(biāo)（事實(shí)上確實(shí)如此，在php3，php4的時(shí)候，已經(jīng)出現(xiàn)了很多成功且足夠復(fù)雜的系統(tǒng)，他們甚至考慮到所有的情況，因此不需要記錄任何log）。但技術(shù)總要向前發(fā)展的，更何況，決大多數(shù)的開發(fā)人員并不具備牛人的嚴(yán)謹(jǐn)?shù)降嗡宦┑乃季S，所以我們還是不得不認(rèn)真思考“如何處理程序錯(cuò)誤”的問題。
上面的“錯(cuò)誤處理+記錄log”的方式，存在如下弊端：
1 如果錯(cuò)誤情況太多，那相應(yīng)的錯(cuò)誤處理代碼需要增加很多，這非常損害程序的可讀性。你的程序看起來是“斷斷續(xù)續(xù)的”。
2 如果程序的邏輯很復(fù)雜（比如程序的函數(shù)調(diào)用非常復(fù)雜，如在 getResult2()函數(shù) 中調(diào)用 getResult() 的情況，甚至更復(fù)雜的多級(jí)嵌套的情況），那錯(cuò)誤數(shù)值的傳遞處理會(huì)讓你疲于奔命。因?yàn)闉榱舜_保錯(cuò)誤能夠得到有效的處理，你必須保證: 以無損耗的方式傳遞錯(cuò)誤數(shù)值。
所以，改變這種原始的錯(cuò)誤處理方式吧。引入異常處理機(jī)制，你會(huì)發(fā)現(xiàn)可喜的變化：
1 代碼可讀性大大增強(qiáng)。開發(fā)程序時(shí)邏輯思維變得很連貫，在“可疑的”地方，你只要拋出個(gè)異常就可以了。至于怎么處理，完全可以等到后面再去補(bǔ)充。當(dāng)然，對(duì)于程序的讀者，也不會(huì)覺得有被打斷的感覺。
2 再也不需要考慮“錯(cuò)誤數(shù)值如何無損耗的進(jìn)行傳遞”這種費(fèi)力又不怎么討好的問題了。因?yàn)楫惓Ｏ蛏蟼鬟f的特性，你的函數(shù)嵌套個(gè)2層，3層，再多層都沒有問題。你只需要在外層有捕獲異常的操作就可以了。
3 異常可以自由的定制，你可以按照功能對(duì)異常進(jìn)行分類，更好的管理各種程序錯(cuò)誤。同時(shí)對(duì)于你也可以更靈活的定制異常的處理方式。比如，在異常類里面實(shí)現(xiàn)記錄log的功能等。
當(dāng)然，是否使用異常要根據(jù)需求而定。php的一大特性就是部署快，如果是很小的項(xiàng)目，邏輯很簡單，那使用一般的錯(cuò)誤數(shù)值處理方式也許能夠更快的部署。
php技術(shù)：PHP 程序員也要學(xué)會(huì)使用“異常”，轉(zhuǎn)載需保留來源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。
