在許多「重異?！?exception-heavy) 的編程語(yǔ)言中，一旦發(fā)生錯(cuò)誤，就會(huì)拋出異常。這確實(shí)是一個(gè)可行的方式。不過(guò) PHP 卻是一個(gè) 「輕異?！?exception-light) 的語(yǔ)言。當(dāng)然它確實(shí)有異常機(jī)制，在處理對(duì)象時(shí)，核心也開(kāi)始采用這個(gè)機(jī)制來(lái)處理，只是 PHP 會(huì)盡可能的執(zhí)行而無(wú)視發(fā)生的事情，除非是一個(gè)嚴(yán)重錯(cuò)誤。

舉例來(lái)說(shuō):

$ php -a php > echo $foo; Notice: Undefined variable: foo in php shell code on line 1

這里只是一個(gè) notice 級(jí)別的錯(cuò)誤，PHP 仍然會(huì)愉快的繼續(xù)執(zhí)行。這對(duì)有「重異?！咕幊探?jīng)驗(yàn)的人來(lái)說(shuō)會(huì)帶來(lái)困惑，例如在 Python 中，引用一個(gè)不存在的變量會(huì)拋出異常：

$ python >>> print foo Traceback (most recent call last):   File "<stdin>", line 1, in <module> NameError: name 'foo' is not defined

本質(zhì)上的差異在于 Python 會(huì)對(duì)任何小錯(cuò)誤進(jìn)行拋錯(cuò)，因此開(kāi)發(fā)人員可以確信任何潛在的問(wèn)題或者邊緣的案例都可以被捕捉到，與此同時(shí) PHP 仍然會(huì)保持執(zhí)行，除非極端的問(wèn)題發(fā)生才會(huì)拋出異常。

錯(cuò)誤嚴(yán)重性

PHP 有幾個(gè)錯(cuò)誤嚴(yán)重性等級(jí)。三個(gè)最常見(jiàn)的的信息類(lèi)型是錯(cuò)誤（error）、通知（notice）和警告（warning）。它們有不同的嚴(yán)重性: E_ERROR 、E_NOTICE和 E_WARNING。錯(cuò)誤是運(yùn)行期間的嚴(yán)重問(wèn)題，通常是因?yàn)榇a出錯(cuò)而造成，必須要修正它，否則會(huì)使 PHP 停止執(zhí)行。通知是建議性質(zhì)的信息，是因?yàn)槌绦虼a在執(zhí)行期有可能造成問(wèn)題，但程序不會(huì)停止。 警告是非致命錯(cuò)誤，程序執(zhí)行也不會(huì)因此而中止。

另一個(gè)在編譯期間會(huì)報(bào)錯(cuò)的信息類(lèi)型是「E_STRICT」。這個(gè)信息用來(lái)建議修改程序代碼以維持最佳的互通性并能與今后的 PHP 版本兼容。

更改 PHP 錯(cuò)誤報(bào)告行為

錯(cuò)誤報(bào)告可以由 PHP 配置及函數(shù)調(diào)用改變。使用 PHP 內(nèi)置的函數(shù) error_reporting()，可以設(shè)定程序執(zhí)行期間的錯(cuò)誤等級(jí)，方法是傳入預(yù)定義的錯(cuò)誤等級(jí)常量，這意味著如果你只想看到警告和錯(cuò)誤 - 而非通知 - 你可以這樣設(shè)定：

<?php error_reporting(E_ERROR | E_WARNING);

你也可以控制錯(cuò)誤是否在屏幕上顯示 （開(kāi)發(fā)時(shí)比較有用）或隱藏后記錄日志 （適用于正式環(huán)境）。如果想知道更多細(xì)節(jié)，可以查看 錯(cuò)誤報(bào)告 章節(jié)。

行內(nèi)錯(cuò)誤抑制

你可以讓 PHP 利用錯(cuò)誤控制操作符 @ 來(lái)抑制特定的錯(cuò)誤。將這個(gè)操作符放置在表達(dá)式之前，其后的任何錯(cuò)誤都不會(huì)出現(xiàn)。

<?php echo @$foo['bar'];

如果 $foo['bar'] 存在，程序會(huì)將結(jié)果輸出，如果變量 $foo 或是 'bar' 鍵值不存在，則會(huì)返回 null 并且不輸出任何東西。如果不使用錯(cuò)誤控制操作符，這個(gè)表達(dá)式會(huì)產(chǎn)生一個(gè)錯(cuò)誤信息 PHP Notice: Undefined variable: foo 或 PHP Notice: Undefined index: bar 。

這看起來(lái)像是個(gè)好主意，不過(guò)也有一些討厭的代價(jià)。PHP 處理使用 @ 的表達(dá)式比起不用時(shí)效率會(huì)低一些。過(guò)早的性能優(yōu)化在所有程序語(yǔ)言中也許都是爭(zhēng)論點(diǎn)，不過(guò)如果性能在你的應(yīng)用程序 / 類(lèi)庫(kù)中占有重要地位，那么了解錯(cuò)誤控制操作符的性能影響就比較重要。

其次，錯(cuò)誤控制操作符會(huì) 完全 吃掉錯(cuò)誤。不但沒(méi)有顯示，而且也不會(huì)記錄在錯(cuò)誤日志中。此外，在正式環(huán)境中 PHP 也沒(méi)有辦法關(guān)閉錯(cuò)誤控制操作符。也許你認(rèn)為那些錯(cuò)誤時(shí)無(wú)害的，不過(guò)那些較具傷害性的錯(cuò)誤同時(shí)也會(huì)被隱藏。

如果有方法可以避免錯(cuò)誤抑制符，你應(yīng)該考慮使用，舉例來(lái)說(shuō)，上面的程序代碼可以這樣重寫(xiě)：

<?php echo isset($foo['bar']) ? $foo['bar'] : '';

當(dāng) fopen() 載入文件失敗時(shí)，也許是一個(gè)使用錯(cuò)誤抑制符的合理例子。你可以在嘗試載入文件前檢查是否存在，但是如果這個(gè)文件在檢查后才被刪除，而此時(shí) fopen() 還未執(zhí)行 （聽(tīng)起來(lái)有點(diǎn)不太可能，但是確實(shí)會(huì)發(fā)生），這時(shí) fopen()會(huì)返回 false 并且 拋出操作。這也許應(yīng)該由 PHP 本身來(lái)解決，但這時(shí)一個(gè)錯(cuò)誤抑制符才能有效解決的例子。

前面我們提到在正式的 PHP 環(huán)境中沒(méi)有辦法關(guān)閉錯(cuò)誤控制操作符。但是 Xdebug 有一個(gè) xdebug.scream 的 ini 配置項(xiàng)，可以關(guān)閉錯(cuò)誤控制操作符。你可以按照下面的方式修改 php.ini。

xdebug.scream = On

你也可以在執(zhí)行期間通過(guò) ini_set 函數(shù)來(lái)設(shè)置這個(gè)值：

<?php ini_set('xdebug.scream', '1')

「Scream」這個(gè) PHP 擴(kuò)展提供了和 xDebug 類(lèi)似的功能，只是 Scream 的 ini 設(shè)置項(xiàng)叫做 scream.enabled 。

當(dāng)你在調(diào)試代碼而錯(cuò)誤信息被隱藏時(shí)，這是最有用的方法。請(qǐng)務(wù)必小心使用 scream ，而是把它當(dāng)作暫時(shí)性的調(diào)試工具。有許多的 PHP 函數(shù)類(lèi)庫(kù)代碼也許無(wú)法在錯(cuò)誤抑制操作符停用時(shí)正常使用。

Error Control Operators

SitePoint

Xdebug

Scream

錯(cuò)誤異常類(lèi)

PHP 可以完美化身為「重異常」的程序語(yǔ)言，只需要幾行代碼就能切換過(guò)去?；旧夏憧梢岳?nbsp;ErrorException 類(lèi)拋出「錯(cuò)誤」來(lái)當(dāng)做「異?！?，這個(gè)類(lèi)是繼承自 Exception 類(lèi)。

這在大量的現(xiàn)代框架中是一個(gè)常見(jiàn)的做法，比如 Symfony 和 Laravel。在調(diào)試（debug）模式 (或叫開(kāi)發(fā)模式) 下，這些框架都能夠展示一份簡(jiǎn)潔干凈的 stack trace。

還有一些對(duì)錯(cuò)誤（error）和異常（exception）的處理更加優(yōu)秀的包（package），例如 Whoops!，它在 Laravel 中是默認(rèn)安裝的并且也可以被用在任意框架中。

在開(kāi)發(fā)過(guò)程中將錯(cuò)誤當(dāng)作異常拋出可以更好的處理它，如果在開(kāi)發(fā)時(shí)發(fā)生異常，你可以將它包在一個(gè) catch 語(yǔ)句中具體說(shuō)明這種情況如何處理。每捕捉一個(gè)異常，都會(huì)使你的應(yīng)用程序越來(lái)越健壯。