2011-10-06 182 views
2

簡寫:當重寫的方法不會拋出異常時,如何拋出異常(或者乾淨利落的清理異常處理;或者至少是骯髒地強制執行以停止) ?重寫方法不會拋出異常時的異常處理

上下文:我們擁有一個可以使用Java「宏」自動化的專有軟件的許可證。用戶定義的宏必須是這個形式:

public class MyMacro extends SoftwareMacro { 
    public void execute() { 
     // user code goes here 
    } 
} 

即該盤區SoftwareMacro並且具有稱爲execute方法,它覆蓋基類的execute的類。這個重要的execute的內容是什麼得到...以及當宏被「播放」時執行。

但是被覆蓋的execute方法顯然不會拋出任何異常。

execute() in com.mycompany.mypackage.MyMacro cannot implement execute() in 
somesoftware.base.SoftwareMacro 
overridden method does not throw java.lang.Exception 

也許這是幼稚的,但在發展中,我通常喜歡有適當的異常類型泡到頂部和力停止執行,這樣我可以看到他們,並繼續調試。這顯然不是一種選擇。

我是不是應該用RuntimeException來代替? (因爲RuntimeException不需要指定)這感覺有點草率,並且是基類方法契約的「精神違反」。

P.S.不,我不能更改被覆蓋的方法的源代碼。

+0

清潔的方法是有一個集中的「例外」處理這將檢測從內部異常的「養」您的覆蓋方法並暫停應用程序執行。實用的方法是拋出一個RuntimeException。 – mcfinnigan

+0

@DaveHowes - 是的,你在誤讀它,對不起。 Java要求重寫方法的異常規範是重寫方法的真正子集;一個空集是課程的一個真正的子集。你不需要拋出與你的超類相同的異常。 –

回答

4

看起來像意圖是,每個SoftwareMacro做自己的錯誤處理。如果需要,在整個​​方法周圍使用大的try,但不要讓任何異常逃脫。如果你的執行方法需要執行任何清理操作,並且可能會爲用戶輸出一條錯誤消息,如果他們提供了這種方法。

您應該檢查它們提供的所有API - 可能是您應該使用的錯誤報告工具。

0

只要execute代碼不吸收異常,它仍然會拋出它,如果遇到一個。如果拋出的異常類型爲RuntimeExceptionRuntimeException的子類,則不需要顯式聲明它們,主要是因爲編譯器沒有強制執行它們的聲明,因爲(正如名稱所暗示的)它們只發生在運行時,並且不能必須在編譯時預測

但是,如果您說過無法修改的execute方法會吸收異常,並且不會通過日誌條目,返回值或某種RuntimeException指示該異常,我認爲您運氣不好。

我同意歐內斯特的看法,意圖是execute方法會自行處理異常。

注意:重寫的方法簽名在涉及到它們拋出的異常時不需要完全匹配 - 只是名稱,返回類型和列表變量類型&。

+0

嗯,不,不完全匹配,但重寫方法僅限於拋出重寫方法的指定異常的子集(並且從不是超集)。 –

4

這一切都取決於「宏播放器」如果遇到運行時異常以及您希望發生的事情時會做什麼。

如果它根本沒有處理它,但是你不在意,拋出一個RuntimeException。

如果它正確處理它們,則拋出RuntimeException。

如果它不能正確處理它們,並且不希望它慘敗,那麼捕獲執行方法中可能發生的異常,並按照您認爲最好的方式處理它們:顯示錯誤對話框輸出錯誤信息,在日誌中記錄一些錯誤...

1

「應該」意味着有一個正確的答案,哪個IMO沒有 做什麼滿足您的需求。

如果系統可以容忍運行時異常,並且它滿足您的需求,爲什麼不呢?

不是你有選擇,因爲你不能拋出一個檢查的異常。

(經過例外似乎是一個失敗的實驗對我來說,雖然我理解的動機。)

+0

好吧,我正在嘗試採用良好的習慣和良好的習慣,這正是「應該」所暗示的。我正在尋找一些比滿足我眼前的需求更有遠見的東西。 –

+0

@ Jean-FrançoisCorbett良好的習慣是......很好,但只有滿足你所要做的事情時才需要。很明顯,作者認爲所有的錯誤處理都應該在宏內完成,並且*可能是恰當的 - 這取決於上下文。但是,通過不提供任何特定於框架的異常簽名,他們已經將您鎖定。考慮Ernest所說的 - 是否存在用於報告錯誤的框架機制?另外,即使系統沒有實際停止*,您仍然可以記錄異常進行檢查。 –