開展會因RuntimeExceptions

假設我有一個方法或使用另一種方法或構造內部構造聲明一個RuntimeException皆可拋聲明。開展會因RuntimeExceptions

// Example: 
public MyClass(Object arg) { 
    setVar(arg); 
    // Not responsible for dealing with the exception 
} 

public void setVar(Object arg) throws MyRuntimeException { 
    if(!isValidArg(arg)) 
     throw new MyRuntimeException("Got you, evil argument!"); 
    // Do something 
}

在這種情況下，如果例如必要的前提條件未滿足，則拋出RuntimeException。

問：包裝方法/構造函數是否應該聲明相同的異常，如果它的參數可能導致異常被拋出？

來源

2013-03-08 Samuel

如何在構造函數中調用實例方法？ – 2013-03-08 12:39:59

@LutzHorn你是什麼意思？爲什麼他不應該這樣做？除非該方法執行重度處理，否則不應該是個問題 – giorashc 2013-03-08 12:41:52

那麼，構造函數應該構造實例。在完全構造之前調用此實例的方法讓我感到奇怪。 – 2013-03-08 12:44:28

這真的取決於代碼是在上下文中，如果你想的東西是自包含的，就像一個圖書館，你可能要趕上內部異常該類，只是爲了使你的代碼更清潔。

但是，如果你正在做的代碼作爲項目的一部分，那麼我會像你說的，「攜帶拋出異常」，直到它沒有任何意義，語義。

來源

2013-03-08 12:41:14 christopher

我認爲「繼續投擲直到沒有意義，語義上」是有道理的。我想說明的是，捕獲一個異常並不總是可能的，儘管你經常只能選擇拋出一個檢查異常，拋出運行時異常並聲明它或不聲明它。 – Samuel 2013-03-08 13:08:07

是的，同意了。 :) – christopher 2013-03-08 13:09:02

RuntimeExceptions拋出，而不需要把它列入了對既不的方法拋出簽名。

你應該閱讀this關於運行時異常

來源

2013-03-08 12:39:59 giorashc

這是正確的，他們不需要被拋出，但有時你想表示可以拋出異常，並讓該類的用戶決定是否他會處理它。例如，如果他傳遞的論點是基於用戶的輸入，並且可能是錯誤的，他可能會抓住它，但是如果他確定它是正確的，他就不會。 – Samuel 2013-03-08 12:46:59

如果是這種情況，那麼爲什麼使用運行時異常？他可以很容易地使用檢查的異常 – giorashc 2013-03-09 12:13:28

我認爲有些人更喜歡拋出檢查，有些人更喜歡拋出未經檢查的異常。在我的情況下，這不是一個選擇點，運行時異常正在拋出，我試圖找到最好的方式來處理它在一個不負責處理的包裝方法。 – Samuel 2013-03-09 16:08:52

我會聲明它，如果它不應該在包裝方法內處理 - 與檢查相同例外。

無論如何，有這樣的暗示甚至對於未檢查的異常的方法。客戶將決定是否需要處理。

來源

2013-03-08 12:44:16

否，運行時異常不會被檢查，即編譯器不會強制您處理它們。但作爲一個良好的編程習慣，你可以處理異常，如

public MyClass(Object arg) { 
    try{ 
    setVar(arg); 
} 
catch(MyRuntimeException exp){ 
    // code if exception arises 
}

來源

2013-03-08 12:47:21 navyad

這是真的，但構造函數可能不負責處理異常。 – Samuel 2013-03-08 12:48:50

這是一個糟糕的主意*通常*在構造函數中捕獲像這樣的異常，除非您非常確信您可以以一種合理的方式來完成對象的構造。如果沒有，最好讓異常傳播給調用者。 – Perception 2013-03-08 12:52:05

如果你從構造函數調用一個方法，並且該方法可能會拋出一個異常，那麼你可能不確定你的對象是否會被構造 – navyad 2013-03-08 12:54:30

開展會因RuntimeExceptions

回答

相關問題