類除了成功之外還拋出異常，這是一種很好的練習/編程形式嗎？

我在寫一些類，想知道如何正確處理不成功的場景。例如，一個文件上傳類，它作爲參數接受$ _FILES資源的名稱：類除了成功之外還拋出異常，這是一種很好的練習/編程形式嗎？

class FileUpload { 
    private $file; 

    public function __construct($file) { 
     $this->file = $file; 
    } 

    public function upload() { 
     if (!isset($_FILES[$this->file])) { 
      throw new Exception("Reference to non existent resource."); 
     } 

     if ($_FILES[$this->file]['error'] !== 0) { 
      throw new Exception("Resource indicates error."); 
     } 

       // All other sorts of checks here, like security checks, 
       // and then finally moving of the file to it's final destination 
    } 
}

這是適當的形式嗎？我的思路是這樣的：當開發者創建一個FileUpload的新實例時，他的意圖是要麼上傳文件，要麼知道爲什麼沒有上傳，而這個類將會給他這個。或者：

1）true（文件被測試的格式是否正確，檢查過安全性，如果它是圖像，甚至可以進一步處理，現在它正是你想要的地方。）

2）異常（出事了，消息是讓你確切地知道，這樣你就可以對付它。）

如果這一切都很好，我應該只使用例外，自定義消息，或爲所有事情創建自定義例外，例如WrongMimeType？

如果很重要 - 類將是開源的，可供所有人使用，所以從這方面我也希望使它們成爲標準化，開發人員友好且可以輕鬆插入現有軟件的儘可能。

來源

2013-10-13 CodeVirtuoso

我會使用自定義異常，他們實際上被多次使用。不要爲一個特定用例使用自定義異常。其實我會認爲這個概念很好。 – bwoebi

這可能應該移到codereview因爲它在我看來像一個關於編碼風格的問題。

但是：

你upload()方法設計很糟糕。它應該接受一個參數，而不是從$_FILES獲取數據 - 外部用戶應該將它傳遞給函數。沒有班級通常應該從超全球或全球變量中獲取數據。

表示拒絕拋出異常的第一個理由。 :)

然後呢？由於沒有太多的代碼可以看到，因此很難進一步討論細節，因此我回到了一般性評論中：

例外情況不應該用作goto的替代品。他們應該發出無法預料的異常狀態。

驗證表單時，無效表單數據不是無法預期的異常狀態 - 它是兩種常見情況之一。實際上，您正在驗證類中的表單數據 - 如果表單無效，則不應拋出異常。

另一件事：不要在異常消息中隱藏錯誤的東西。如果我無法捕捉到使用多個catch語句拋出的不同異常類，但卻不得不查看這些消息，這使得使用該類變得非常困難。

而且因爲您問的是讓其他人可以使用該代碼：使用名稱空間，兼容PSR-0的自動加載和您自己的異常類。並且不要從超級全球採集數據。

來源

2013-10-13 17:44:17 Sven

非常感謝您的詳細解答和參考。只有一件事，仍然讓我感到困惑。「他們應該發出無法預料的異常狀態。「什麼應該被用於不期望的狀態，可以預期？我嘗試過的事情：1）返回false：葉更少線索出錯2）創建一個$狀態數組，然後包含'成功'，'信息'和'錯誤'數組基本上包含了所有發生給定方法調用的小日誌：看起來太麻煩而且隨機 - 我敢肯定有人想出了一個更好的方法。那麼...什麼是正確的方式？ – CodeVirtuoso

好吧，在某種程度上，所有異常的狀態都應該以某種方式被預期，否則你將無法編寫拋出異常的代碼。我的觀點是：稀疏地使用異常。它們通常應該表示「我們知道世界的盡頭」，在至少對於拋出它的類來說，即沒有有用的方法來繼續操作，調用一個沒有上傳文件的上傳類可能就是這種情況，但我認爲這是輸入驗證的任務 - 並且驗證可以成功或不是（返回true或false），可能是e xplain在問及時出了什麼問題。 – Sven

類除了成功之外還拋出異常，這是一種很好的練習/編程形式嗎？

回答

相關問題