2017-02-01 3 views
2

それを整理する方法は、私は例外の巨大な家族のいる:巨大な例外群です。

class A extends Exception {} 
class A1 extends A {} 
class A2 extends A {} 
... 
class A40 extends A {} 

も例外では「修理」することができますが、すべての例外は、ユーザーにエラーとして表示されなければなりません。すべての例外(型)は別の情報を持ちますので、例外の数を減らすことはできません。ユーザーに通知する必要があるため、スローされた例外はすべてGUIに「プル」されます。

問題がありますか?どうして?たとえば、次のように

private void f() throws A1, A2, ..., A20 {} 

Aいくつかのソリューション(*)は次のようになります。あなたはどう思います

void function_in_GUI(){ 
try { 

} catch(A a){ 
    handle(a); 
} 

void handle(A a){ 
    try{ 
    throw a; 
    } catch(A1 a){ 
    notify_user(); 
    } catch(A2 a){ 
    .... 
    } 
    .... 

} 

} 
  1. private void f() throws A {} 
    

    そして、例外の種類を "回復" します(*)?

  2. それを行うにはcannonical方法...のRuntimeExceptionを拡張
+0

これらの例外に共通するものは何ですか?異なる属性を持つ同じExceptionクラスにすることはできますか? –

+1

* "...別の情報なので、例外数を減らすことはできません" * - 私は真剣にそれを減らすことはできないと疑っています。 –

+2

標準的な方法は、膨大な量の例外を作成することではありません。この1つの例よりも20年で例外は少ないと書いています。 – Kayaman

答えて

0

はここに多くの利点を持っています。あなたは実行ファイルを宣言したり捕捉したりする必要はありませんが、RuntimeExceptionを一箇所で捕捉して、ユーザーに余分な情報の問題を示すだけです。

2

理想的には、クラスAのメソッドの基本実装を行い、そのメソッドをサブクラスA1、A2、...、A40でオーバーライドすると、各サブクラスは独自のカスタム実装を提供します。その方法。あなたがそのような構造を持っているなら、エレガントに扱うことができます。

void function_in_GUI(){ 
    try { 

    } catch(A a){ 
     SomeInfo someInfo = a.someMethod(); 
     notify_User(someInfo); 
    } 
} 

アイデアは、あなただけの実行時に発生した例外からいくつかの情報を取得するために、個々の例外をキャッチする必要がないことです。

+1

良い答え。例外処理がユーザーに通知するだけであれば、各例外を個別にキャッチする必要はありません。おそらく、それほど深い例外クラス階層を持つ必要はないでしょうか? '各例外は別の情報を持ちます'しかし、この情報がGUI用のものであれば、一般的な構造(GUIメッセージ用)は必要なものすべてですか? フィールドとして元の例外を常に保持する必要があります。根本原因が記録/デバッグされる可能性があります。 –