次の例外処理の何が問題になっていますか...これは正しくないと言われましたが、今では私の例外処理は最高ではありません...
try {
} catch (UnsupportedEncodingException | HttpException e) {
} catch (IOException e) {
}
何かガイダンスはありますか?
次の例外処理の何が問題になっていますか...これは正しくないと言われましたが、今では私の例外処理は最高ではありません...
try {
} catch (UnsupportedEncodingException | HttpException e) {
} catch (IOException e) {
}
何かガイダンスはありますか?
その例外に固有のアクションを実行できるように、各例外を個別のcatchブロックで処理することを常にお勧めします。
これはJava7以降は許容できる構文ですが、(比較的)新しいため、一般的なイディオムはキャッチごとに1つのタイプを処理することです。この構文で問題がないのは、catchがcatch内のすべてのタイプでまったく同じ動作を実行し、それでも...
また、例外の階層にも注意する必要があります。倍数は左から右に評価されると思いますが、それに依存する前にそれを確認する必要があります。
HttpException
扱い方との間に悪いことはないと思いますIOException
。
例外処理の最も重要な部分は、次のことを確認することです。
あなたは例外を除いて何かをすることができます。何もできない場合の最善の戦略は、例外を再スローすることです(おそらく、アプリケーションの上位層にとってより意味のある例外でそれをラップします)。
各例外をスローする可能性のある条件の違いを理解しています。
たとえばUnsupportedEncodingException
、Javaが指定されたエンコーディングを処理できないことを意味します。一部のWSAPIを使用している場合は、メッセージ形式がおそらく正しくないことを意味します(Javaは標準のエンコーディングのほとんどを処理するため、メッセージが不良である可能性が高くなります)。これは、サポートされていないエンコーディングでIOException
を作成する場合にJavaによってスローされるサブクラスであることに注意してください。Reader
HttpException
HTTP障害応答を受信したことを意味します。IOException
「データ転送」が良かったのでそうではありません。接続ではなく、サーバーからのエラーを示しています。
IOException
ストリームの処理中に何か問題が発生したことを意味します(ストリームが予期しない方法で終了した可能性があります)。
各エラーの原因に基づいて、コードで「悪い」のはミックスインUnsupportedEncodingException
と。だけHttpException
です。例外ハンドラで何をするかによって異なりますが、どちらの例外にも原因が異なります。