5

ある種のビジネス データを JSON 文字列にエンコードするコードがあります。

public String encodeDataAsJsonString(Data data) throws JSONException {
    JSONObject o = new JSONObject();
    o.put("SomeField1", data.getSomeProperty1());
    o.put("SomeField2", data.getSomeProperty2());
    ...
    return o;
}

問題は次のとおりです。

  • JSONException はチェック例外ですが、
  • コンパイル時にそれを処理する方法がよくわかりません。JSONException が実際に発生した場合、それはおそらくコードのバグであり、既にそこにあり(例: this )、必要なすべてのログ記録とクリーンアップを既に実行している通常の「キャッチされていないグローバル例外ハンドラー」によって処理する必要があります。

したがって、呼び出し元のメソッドでこれを行うことになりました。

...
try {
    encoded = encodeDataAsJsonString(data);
} catch (JSONException e) {
    throw new RuntimeException(e);
}
...

コールスタックのすべてthrows JSONExceptionのメソッドに aを追加するよりも、害が少ないように思えました。しかし、それはまだ汚れているので、私の質問は次のとおりです。

特定のチェック済み例外を「通常の未チェック例外ルート」に送りたい場合、それを RuntimeException として再スローするのが正しいイディオムですか?

4

6 に答える 6

6

状況は非常に単純です。例外にビジネス上の価値がない場合、つまり単なる失敗である場合は、必ず未チェックの例外を使用してください。その例外に固有の方法で例外を処理する必要がある場合 (ほとんどの場合、処理コードがビジネス ロジックを含むことを意味します)、未チェックの例外を使用しても問題ありませんが、少なくともいくつかの利点があります。チェック例外。ただし、どちらの場合でも、JSON API から取得した生の例外は役に立たず、パブリック API の設計が不適切であることを示しているにすぎません。

補足として、ラップせずに元のチェック済み例外をスローできるようにする「こっそりスロー」イディオムがあります。

public static <R> R sneakyThrow(Throwable t) {
  return UncheckedThrower.<RuntimeException, R>sneakyThrow0(t);
}
@SuppressWarnings("unchecked")
private static <E extends Exception, R> R sneakyThrow0(Throwable t) throws E { throw (E)t; }

言うまでもなく、プロジェクトでこのアプローチを使用する場合は十分に注意する必要があります。

于 2012-10-22T17:45:19.443 に答える
5

短い答え、はい。

おそらく、独自の例外クラス (ランタイム例外の子) を作成し、それを再スローして、必要に応じてドキュメント化、キャッチ/処理を容易にすることができます。HibernateException を使用して hibernate のようなことを行うと、クライアント/呼び出しコードはそれを強制的にキャッチする必要はありませんが、論理的/アプリケーション固有の何かを実行できる場合は常にキャッチできます。

于 2012-10-22T17:32:06.347 に答える
2

アプリケーションコードで例外を処理するつもりがない場合は、それを としてスローできますRuntimeException。

com.google.common.base.Throwables私はこれを広めるために使用することを好みます。

于 2012-10-22T17:57:11.337 に答える
1

Java コードで未チェックの例外のみを使用するための引数があります。そのアプローチに従いたい場合は、チェック済みの例外をラップすることが唯一の賢明なことです。FWIW、私はこのアプローチを何度も使用しており、役に立ちました。

そのスタイルに同意したくない場合でも、一部のチェック済み例外を実行時例外に変換すると便利な場合があります。

于 2012-10-22T17:33:39.980 に答える
1

私はいつもこれをしています。はい、それは良いアプローチです。いいえ、それは汚いアプローチではありません。個人的には、チェック例外に耐えられません。例外の種類に関係なく、すべてのチェック済み例外を実行時例外としてラップします。

于 2012-10-22T17:33:46.377 に答える
0

チェック例外は、開発者間の通信手段です。チェックされた例外は「私を処理してください」と言っています。自分が何をしているのかわかっている場合は、例外を再スロー (およびログ) することができます。

編集:他の回答と同様に、例外の再ラップも良いアドバイスです。

于 2012-10-22T17:33:21.507 に答える