2013-03-21 2 views
5

は、コードのこの作品は、20ヶ所にあり、常に同じキャッチ個別の例外をまたはinstanceofを使用 - Java 6の

try { 
    // do something 
} catch (FirstException e) { 
    // log it 
} catch (SecondException e) { 
    // log it 
} 

ているとは、このまたはinstanceof良い解決策ではないようなものを使用する方が良いと思いませんか?私は本当にソリューションについて嫌い

try { 
    // do something 
} catch(Exception e) { 
    logException(e); 
} 

void logException(Exception e) { 
    if (e instanceof FirstException) { 
     // log it 
    } else if (e instanceof SecondException) { 
     // log it differently 
    } else { 
     // do something with other exception 
    } 
} 

唯一のものは、任意のより良い方法はあります... definitelly最善の方法ではありませんどのExceptionを引くのですか?

+0

私は最初のアプローチを使用し、捕捉されたすべての例外に対してlogExceptionを呼び出します。 – Thihara

+0

'FileNotFoundException'がスローされたらどうなりますか? – Azodious

+0

各例外をキャッチすることは、それぞれ異なる処理を行う場合にのみ意味があります。実際のアプリケーションでは、これはまれです。実現可能なアプローチは、ランタイムエラーが重大な懸念事項であり、実際にどこで何が起きたのかを開発者に理解させるために、スーパークラス '例外'または 'Throwable'を使用してem 'をすべてキャッチすることです。 – Vrushank

答えて

8
  1. 、あなたは、あなたがすべての例外を記録したいんcatch (FirstException1 | SecondException | ...)
  2. catch (Exception e) —と間違って何もないかもしれないしていないでしょうか?私は実際にに助言します。OutOfMemoryErrorStackOverflowErrorもログに記録したいからです。

ロギング例外に関する長年の経験から、アドバイスはすべて同様にログに記録することです。例外メッセージは人が読めるテキストで十分です。開発者がデバッグに本当に必要とするのはスタックトレースです。

だけで一つのことにご注意:早すぎる例外をキャッチすることはありません:アプリケーション全体のための単一の場所でそれらをキャッチし、例外バリアいわゆる —それはあなたが入力したとのユニットを出るレベルであります作業。

チェック例外はRuntimeExceptionにそれらをラップし、下位レベルであなたにトラブルを与えている場合:

try { 
    ... 
} 
catch (RuntimeException e) {throw e;} 
catch (Exception e) {throw new RuntimeException(e);} 

のみあなたは、ビジネス・レベルの意味を持つ例外があることを正確に事前にわかっている場合ではなく、は現在の作業単位を中止しますが、そのフローをリダイレクトするため、その例外をより低いレベルで捕捉することは適切ですか?実際には、そのような例外は、アプリケーションコードによって発生するすべての可能性のある例外の総数と比較して稀です。

+2

Throwableをすべての最大の悪のようにキャッチしていませんか?私はすべての例外をキャッチしたくないので...ただ2つ – user219882

+0

あなたがそれらをあまりにも早くキャッ​​チする場合 - 私は編集された答えで説明します。 –

+0

ありがとうございます - あなたが例外をキャッチできるかどうかわからなかった| bはJava 7で(主にObj-Cで動作しています)。 。 。便利なチップ。 –

1

最初のアプローチは間違いなく優れています。一般に、Exceptionを捕まえることは悪い習慣です。この場合、RuntimeExceptionも捕まえるからです。

1

Formerは、例外を記録するだけであればクリーンで優れたソリューションです。

これ以外の場合は、最初の方法が優れています。 Javaの7では

1

"Refactoring to Patterns"という本の中で、一般的なリファクタリングの1つは "instanceofを多態性に置き換える"ことです。言い換えれば、instanceofを使用するときは常にポリモルフィズムがうまく機能するかどうかを検討してください。 。 。

この特定の質問に対して、チェックされた例外を実行時の例外に置き換えるSpringの哲学は、気が向いています(言い訳を言い訳します)。

考えられるのは、チェックされた例外が過度に使用される可能性があるということです。はいの場合はOKです。 。 。そうでなければ、チェーンの上に伝播させてください。

  • 再投げてください。 。 。 (より良いまだ)
  • ログアスペクトの作成のRuntimeExceptionに

を包み:考慮すべき

もう一つは、あなたがしなければ、彼らが発生し、正確時点でこれらの例外をログに記録する必要があるということですは20の異なる場所で発生していることを示しています。 。 。あなたは、例外を再現するだけの通常の方法を持っていて、それをキャッチしてログに記録するという側面を書くことができます。 。 。 。再びSpringを使用すると、これは簡単になります。

関連する問題