PHP中異常處理的方法

本篇文章主要介紹PHP中異常處理的方法，感興趣的朋友參考下，希望對大家有所協助。

每一個新的功能添加到PHP運行時會建立一個指數隨機數，通過這樣的方式開發人員可以使用和甚至濫用這個新特性。然而，直到一些好的和壞的使用方式陸續出現開發人員們才達成了共識。當這些新案例不斷浮現，我們終於可以辨別出什麼是最好或最壞的做法。

異常處理在PHP中的確無論如何都不算是一個新的特徵。但在本文中，我們將討論在PHP 5.3中基於異常處理的兩個新的特點。第一個是嵌套異常第二是一套SPL（現在的PHP運行機制的一個核心擴充）的擴充的新的異常類型。這兩個新特性，這本書裡都能找到最佳實務值得各位去詳細研究。

特別要注意：這些特性中的一些已經存在於低於5.3的PHP版本之中，或者至少能夠在低於5.3的版本之中被實現. 而當本文提到 PHP 5.3, 並不是嚴責意義上的 PHP 運行時版本. 相反，它意味著程式碼程式庫和項目是採用 PHP 5.3 作為最低版本的，但同時也是在新的發展階段出現的所有最佳實務. 這個發展階段所凸顯的是特定的幾個像Zend Framework, Symfony, Doctrine 以及 PEAR 這樣的項目所進行的“2.0”嘗試.

背景

PHP 5.2 只有一個異常類 Exception。按照 Zend Framework / PEAR 的開發標準， 這個類是你的庫中所有異常類的基類。如果你建立一個名叫 MyCompany 的庫，按 Zend Framework / PEAR 的標準， 庫中所有的代碼檔案都會以 MyCompany_ 開頭。要是你想給庫建立自己的異常基類: MyCompany_Exception, 那就用該類繼承 Exception，然後再由組件(component )繼承和拋出該異常類。比如你有一個組件 MyCompany_Foo，你可以給它建立一個用在該組件內部的異常基類 MyCompany_Foo_Exception。這些異常能被捕捉 MyCompany_Foo_Exception，MyCompany_Exception 或 Exception 的代碼捉到。 對於庫中其他用到該組件的代碼來說，這是個三層的異常(或更多，取決於 MyCompany_Foo_Exception 的子類有幾層 )， 他們可以根據自己的需要處理這些異常。

在php5中，基本異常類已經支援嵌套的特性了。什麼是嵌套呢？嵌套是一種能力可以去捕獲特殊異常，或者捕獲參照原始異常而建立的一個新的異常對象。這將會允許caller屬性在更公開的類型的開銷庫中出現的兩種異常類上得到體現，當然也會在具有原始異常行為的異常類上體現。

為什麼這些特性很有用？通常，通過使用其他代碼來拋出自己的類型的異常是最有效代碼。這些代碼可能是使用適配器模式封裝的提供一些適應性更強強的函數的第三方程式碼程式庫的代碼，或利用一些PHP擴充來拋出異常的簡單代碼。

例如，在組件 Zend_Db 中, 它使用了適配器模式來封裝特定的 PHP 擴充，來建立一個資料庫抽象層. 在一個適配器中, Zend_Db 封裝了 PDO, 而 PDO 會拋出它自己的異常 PDOException, Zend_Db 需要捕獲這些特定於 PDO 的異常，並讓它們以可預期且類型已知的 Zend_Db_Exception 重新被拋出. 這樣就給了開發人員保證， Zend_Db 將總是拋出 Zend_Db_Exception 類型的異常(因此可以被捕獲), 而他們同時也可以在需要的時候訪問到最開始被拋出的 PDOException.

下面的樣本展示了一個虛構的資料庫適配器可能如何去實現嵌入式的異常:

class MyCompany_Database{ /**  * @var PDO object setup during construction  */ protected $_pdoResource = null;   /**  * @throws MyCompany_Database_Exception  * @return int  */ public function executeQuery($sql) {  try {   $numRows = $this->_pdoResource->exec($sql);  } catch (PDOException $e) {   throw new MyCompany_Database_Exception('Query was unexecutable', null, $e);  }  return $numRows; } }

為了使用嵌入式的異常，你就得調用被捕獲異常的getPrevious()方法:

// $sql and $connectionParameters assumedtry { $db = new MyCompany_Database('PDO', $connectionParams); $db->executeQuery($sql);} catch (MyCompany_Database_Exception $e) { echo 'General Error: ' . $e->getMessage() . "\n"; $pdoException = $e->getPrevious(); echo 'PDO Specific error: ' . $pdoException->getMessage() . "\n";}

大多數最近被實現的PHP擴充都擁有OO（物件導向）介面. 因此，這些API傾向於拋出異常，而不是發生錯誤終止。PHP中能夠拋出異常的擴充，稍微列舉出幾個就包括有PDO, DOM, Mysqli, Phar, Soap 以及 SQLite.

新特性：新核心異常類型

在PHP 5.3開發中，我們展示了一些有趣的新異常類型。這些異常在PHP 5.2.x中已經存在，但最近還沒到“重新評估”異常的最佳實務，現在他們會顯得更加引人注目。他們在SPL擴充中得以應用，並在手冊中列出（這裡）由於這些新的異常類型是PHP核心的一部分，也是SPL的一部分，它們可以被任何用PHP 5.3（及以上）運行代碼的人使用。雖然在編寫應用程式層的代碼時，看起來不那麼重要，但在我們寫或者使用程式碼程式庫時，使用這些新異常類型變得更加重要

那麼為什麼新異常是普通類型？以前，開發人員試圖通過在異常訊息提醒中放入更多的內容來賦予異常更多的含義。雖然這樣做是可行的，但是它有幾個缺點。一是你無法捕獲基於訊息的異常。這可是一個問題，如果你知道一組代碼是同樣的異常類型與不同的提示訊息對應不同異常情況下，處理起來的難度將相當的大。例如，一個認證類，在對$auth->authenticate();；它拋出異常的相同類型的（假設是異常），但不同的訊息對應兩個具體的故障：產生故障原因是證明伺服器不能達到但是相同的異常類型卻提示失敗的驗證訊息不同。在這種情況下（注意，使用異常可能不是處理認證響應最好的方式），這將需要用字串來解析訊息從而處理這兩種不同的情況。

這個問題的解決辦法顯然是通過某種方式對異常進行編碼，這樣就可以在需要辨別如何對這種異常環境做出反應的時候能夠更加容易的查詢到。第一個反應庫是使用異常基類的$code屬性。另一個是通過建立可以被拋出且能描述自身行為的子類或者新的異常類。這兩種方法具有相同的明顯的缺點。兩者都沒有呈現出想這樣的最好的例子。兩者都不被認為是一個標準，因此每個試圖複製這兩種解決方案的項目都會有小的變化，這就迫使使用這需要回到文檔以瞭解所建立的庫中已經有的具體解決方案。現在通過使用SPL的新的類型方法，也稱作php標準庫；開發人員就可以以同樣的方式在他們的項目中，並且複用這些項目的新的最佳的方法已經出現。

第二個缺點是使用詳細資料的做法使得理解這些異常情況對那些非英語或英語能力有限的開發人員來說十分困難。這可能會使的開發人員在試圖理解異常資訊的含義的過程十分的緩慢。許多開發人員也會寫關於異常的文章，因為還未出現一個統一的整合過的標準所要有同這些開發人員數量相同的不同的版本來描述異常訊息所描述的情況。

所以我如何去使用它們，就用這些讓人無語的密密麻麻的細節描述？

現在在SPL中有總共13個新的異常類型。其中兩個可被視為基類：邏輯異常和運行時異常;兩種都繼承php異常類。其餘的方法在邏輯上可以被拆分為3組：動態調用組，邏輯組和運行時組。

動態調用組包含異常 BadFunctionCallException和BadMethodCallException，BadMethodCallException是BadFunctionCallException（LogicException的子類）的子類，這意味著這些異常可以被其直接類型（譯者註：就是異常自身的類型，大家都知道異常有很多種）、LogicException，或者Exception抓到（譯者註：就是catch）你應該在什麼時候使用這些？通常，你應該在由一個無法處理的__call()方法產生的情況，或者回調無法不是一個有效函數（簡單說，當某些東西並非is_callable()）時使用。

例如：

// OO variantclass Foo{ public function __call($method, $args) {  switch ($method) {   case 'doBar': /* ... */ break;   default:    throw new BadMethodCallException('Method ' . $method . ' is not callable by this object');  } } } // procedural variantfunction foo($bar, $baz) { $func = 'do' . $baz; if (!is_callable($func)) {  throw new BadFunctionCallException('Function ' . $func . ' is not callable'); }}

一個直接的例子，在__call時call_user_func()。這組異常在開發各種API動態方法的調用、函數調用時非常有用，例如這是一個可以被SOAP和XML-RPC用戶端/服務端能夠發送和解釋的請求。

第二組是邏輯（logic ）組。這組由DomainException、InvalidArgumentException、LengthException、OutOfRangeException組成。這些異常也是LogicException的子類，當然也是PHP的Exception的子類。在有狀態不定，或者錯誤的方法/函數的參數時使用這些異常。為了更好地理解這一點，我們先看看最後一組異常

最後一組是運行時（runtime ）組。它由OutOfBoundsException、OverflowException、RangeException、UnderflowException、UnexpectedValueExceptio組成。這些異常也是RuntimeException的子類，當然也是PHP的Exception的子類。在“運行時”（runtime）的函數、方法發生異常時，這些異常（運行時組）會被調用

邏輯組和運行時組如何一起工作？如果你看看對象的剖析，通常是發生的是兩者之一。首先，對象將跟蹤並改變狀態。這意味著對象通常是不做任何事情。它可能會傳遞結構給它，它可能會通過setter和getter設定一些東西（譯者註：例如$this->foo='foo'），或者，它可能會引用其他對象。第二，當對象不跟蹤或改變狀態，這代表正在操作——做它該做的事。這是對象的運行時（runtime）。例如，在對象的一生中，它可能被建立，設定一些東西，那麼它可能會被setFoo($foo),setBar($bar)。在這些時候，任何類型的LogicException應該被提高。此外，當對象內的方法被帶參數調用時，例如$object->doSomething($someVariation);在前幾行檢查$someVariation變數時，可能拋出一個LogicException。完成檢查$someVariation後，它繼續做它該做的doSomething()，這時被認為是它的“運行時”（runtime），在這段代碼中，可能拋出RuntimeExcpetions異常。

要理解得更好，我們來看看這個概念在代碼中的運用：

class Foo{ protected $number = 0; protected $bar = null;  public function __construct($options) {  /** 本方法拋出LogicException異常 **/ }   public function setNumber($number) {  /** 本方法拋出LogicException異常 **/ }   public function setBar(Bar $bar) {  /** 本方法拋出LogicException異常 **/ }   public function doSomething($differentNumber) {  if ($differentNumber != $expectedCondition) {   /** 在這裡，拋出LogicException異常 **/  }     /**   * 在這裡，本方法拋出RuntimeException異常   */  } }

現在理解了這一概念，那麼，對程式碼程式庫的使用者來說，這是做什麼的呢？使用者可以隨時確定對象的異常狀態，他們可以用異常的具體的類型來捕獲(catch）異常，例如InvalidArgumentException或LengthException，至少也是LogicException。通過這種層級的精度調整，和類型的多樣，他們可以用LogicException捕獲最小的異常，但也可以通過實際的異常類型獲得更好的理解。同樣的概念也適用於運行時的異常，可以拋出更多的特定類型的異常，並且不論是特定或非特定類型的異常，都可以被捕獲（catch）。它可以給使用者提供更詳細的情況和精確度。

下面是一個關於SPL異常的表，您可能會有興趣

類庫代碼中的最佳實務

PHP 5.3 帶來了新的異常類型, 同時也帶給我們新的最佳實務. 除了將某些特定的異常(如: InvalidArgumentException, RuntimeException)標準化外, 捕捉組件級的異常, 也很重要. 關於這方面, ZF2 wiki 和 PEAR2 wiki 上面有深入的探討.

簡而言之, 除了上面提到的各種最佳實務, 我們還應該用 Marker Interface 來建立一個組件級的異常基類. 通過建立組件級的 Marker Interface, 用在組件內部的異常既能繼承 SPL 的異常類型, 也能在運行時被各種代碼捕捉. 我們來看下列代碼:

// usage of bracket syntax for brevitynamespace MyCompany\Component {  interface Exception {}  class UnexpectedValueException   extends \UnexpectedValueException   implements Exception {}  class Component {  public static function doSomething()  {   if ($somethingExceptionalHappens) {    throw new UnexpectedValueException('Something bad happened');   }  } } }

如果調用上面代碼中的 MyCompany\Component\Component::doSomething() 函數, doSomething() 拋出的異常可以當作下列異常類型捕捉: PHP 的 Exception, SPL 的 UnexpectedValueException, SPL 的 RuntimeException, 該組件的MyCompany\Component\UnexpectedValueException, 或該組件的 MyCompany\Component\Exception. 這為捕捉你的類庫組件中的異常提供了極大的便利. 此外, 通過分析異常的類型, 我們也能看出某個異常的含義.

總結：以上就是本篇文的全部內容，希望能對大家的學習有所協助。

相關推薦：

使用Snoopy類解析html檔案的方法

php針對數組的刪除、轉換、分組、排序

php針對檔案操作及字串加密的方法