2014-04-12 76 views
0

是否應該拋出沒有消息的異常?在什麼情況下?例如,當子類化爲Exception時,是否應該提供一個沒有參數的構造函數?應該拋出沒有消息的異常嗎?

public class LexerException extends Exception { 
    public LexerException(String message) { 
     super(message); 
    } 
} 

public class LexerException extends Exception { 
    public LexerException() { 
     super(); 
    } 
    public LexerException(String message) { 
     super(message); 
    } 
} 
+1

爲什麼所有的downvotes? – Kyranstar

+0

這是一個完全主觀的情境問題。 –

+0

通常,您應該避免自定義異常。使用已經存在的。 – mre

回答

3

是否應該拋出沒有消息的異常?在什麼情況下?

沒有消息的異常會在任何時候拋出一些代碼實例化並拋出一個沒有消息的異常。任何人都可以編寫這樣的代碼。

當然,如果您試圖拋出的異常不允許您在沒有消息的情況下實例化該消息...或者使用null消息......則您不能。但我從來沒有遇到一個異常類,堅持異常是非空。

異常的一種情況通常沒有消息的時候是NullPointerException當它被JVM本身拋出時。


如果你問應該把它...在它是否是編寫拋出異常沒有消息代碼良好實踐意義上說,答案是(IMO)不可以,但你可以彌補你自己的想法。 (我想,如果異常的名字說,所有有可說的,然後會有一個消息是多餘的。但是,它始終是非常有用的調試時,有額外信息的堆棧跟蹤。)


重新這些評論:

通常,您應該避免自定義異常。使用已經存在的。 - mre

爲什麼我應該避免自定義異常? - Kyranstar

的一點是,之前,你編寫一個自定義異常,你應該看看是否有一個現有的異常,這意味着同樣的事情,你提出的新的。例如,當存在符合您的用途的現有IllegalArgumentException時,請勿寫入自定義IllegalLexerArgumentException例外。

爲什麼?

  1. 出於同樣的原因,我們不寫(說)自定義集合類沒有很好的理由。編寫不必要的代碼是一個糟糕的主意,因爲這只是編譯和測試的更多代碼,運行時需要更多空間,維護人員需要讀取更多代碼等。

  2. 因爲擁有大量異常類同樣的事情可以使異常處理混亂。隨着您組合/重新使用更多庫來製作大型應用程序,這種效果變得更糟。

0

如果你不給除外的任何消息,因此您可以彈出消息到花葯的位置,當你的錯誤,但它的建議給每個異常你創建消息並創建此異常的實例並將其拋出。

0

如果文檔明確指出存在觸發異常的單個案例,那麼恕我直言,不需要在異常中有消息。否則,它是。一個好的經驗法則是:讓那些打算使用/調試該代碼的人輕鬆一下。

0

好吧,老實說,我剛剛搜索我們的代碼,我們使用無例外的消息,但他們真的很明顯的。像:

UsernameCantBeEmptyException// example only 
0

我認爲這取決於用例。例如NullPointerException沒有消息。有什麼可能有幫助?不知道。另一方面,那裏的ClassCastException沒有消息的Java版本。這是非常令人興奮的,因爲應該播出的類型很難找出並且可用於該程序。

只要我不知道跳過消息的用例似乎適用,我不會提供空的構造函數。 AFAIK一個詞法分析器會指出這個變量的類型,因此這個變量是否合適。這將表明,甚至必須向最終用戶呈現異常消息。在這種情況下,甚至本地化可能是強制性的。如果是這樣,甚至有些'工廠基礎設施'可能是一個好主意。

關於自定義異常的一般情況:有這樣的趨勢經常發生,然後很多人發現實際上並沒有需要自定義異常。事實上,甚至有一些不需要單獨的程序。在業務上,我參與了一個200kLOC項目,我認爲我們沒有一個。但是對於具有特定處理需求的子系統(比如捕獲所有的LexerException以特定的方式顯示它們,將它們與編程中的錯誤分開,無論如何),這可能很有意義。我正在開發一個小型的OSS項目,在那裏我甚至有不止一個。但是您應該始終記住,額外的異常類型必須使異常處理更簡單,不會更復雜。如果你一個接一個地有幾個catch塊,那麼你肯定會在錯誤的軌道上。這是不必要的自定義例外的典型症狀。

相關問題