2012-05-11 192 views
3

在拋出異常時將對象傳遞給構造函數是一個好主意嗎?Java:拋出異常

讓我們假設服務包中有下一個代碼。

throw new MyException(object); 

MyException類:

Object object; 
public MyException(Object object) { 
    super(); 
    this.object = object; 
} 

public Object getObject() { 
    return object; 
} 

後來,我們說,在GUI我們必須處理服務引發的異常。我們只是捕獲一個異常並且想要訪問在構造函數中傳遞的對象。這工作。但從風格的角度來看它是否正確?

getObject()的使用是否正確?

+0

我需要這個對象來將它放入稍後應該處理的對象隊列中。 – positiveAlex

回答

2

我想說這取決於你在做什麼getObject。如果您只是用它來報告錯誤或管理異常中的恢復,那麼這沒有任何問題。我會傳遞比對象更具體的東西。例如,我可能會提供有關錯誤原因的異常信息,並捕獲可能有助於解決錯誤的任何有用信息。

另一方面,如果您正在使用此對象來繼續控制流的某些正常分支,那麼這將不被視爲正常使用異常!要重複這些明顯的例外情況,除了特殊情況外,別無其他。如果你對他們做別的事情,這通常是個壞主意。

如果您使用異常來捕獲稍後處理的結果,那麼這是一種糟糕的設計異味。查看重構代碼以將這些對象寫出到商店以供稍後進行處理,或者等等。不要濫用例外。

+0

Effective Java#63推薦的第一部分:-) – assylias

+0

邪惡aka不這樣做嗎? –

+0

@Perry:國際海事組織不是「邪惡」,而是「壞」,如「只有在你確定替代品更糟糕時才這樣做」。 –

0

一般來說,是的,將數據添加到異常對象中可能對處理異常的代碼有用。

但是,返回ObjectgetObject()方法過於通用 - 方法的名稱以及對象的類型應該特定於該例外 - 如果需要,則創建多個例外類,然後您可以區分它們在catch塊。

最後,這種事情可能會被濫用於正常的控制流程。我不同意這種標準教條,認爲這本質上是「邪惡的」 - 例外控制流程機制。但是它們對於可維護性來說是不利的,因爲它隱式地連接了一些代碼。所以它只能用於如果你真的需要一種方法來將控制流傳遞給調用堆棧的幾個級別,並且很難考慮替代方案。

+0

我在示例中只用Object來描述問題。實際上,真實代碼更具體。 – positiveAlex

0

一如既往,它將取決於您的系統結構和您想要實現的目標,但IMO還是一個可以接受的方法。

事實上,這是默認異常API處理錯誤消息和原因的方式,將它們作爲構造函數參數傳遞(請參閱Exception構造函數API Doc)以供稍後處理。

0

捕獲異常的類取決於封裝在異常中的對象的(靜態)類。最小化依賴關係通常是一個好主意。這就是爲什麼我不會將組件內部的類封裝到異常中。只有當異常和封裝類屬於同一個組件時,我纔會將組件的公共類封裝在異常中。