問題タブ [checked-exceptions]

ランタイム例外とは何ですか？チェックされた/チェックされていない例外とは何ですか？エラー/例外の違いなぜこれらの多くのタイプですか？代わりに、Javaは単純な設計（すべてのタイプを試して/キャッチするだけ）に従って、プログラムの異常な状態を処理することができますか？

私は次のような方法を持っています：

これにより、「すべてのコード パスが値を返すわけではありません」というコンパイラ エラーが発生します。しかし、私の場合、ThrowSpecificFault() は常に (適切な) 例外をスローします。だから私は最後に戻り値を置くことを余儀なくされていますが、これは醜いです。

そもそもこのパターンの目的は、「process()」が外部 Web サービスへの呼び出しであるが、クライアントの予想されるインターフェイス (~facade パターンだと思います) に一致するようにさまざまな異なる例外を変換する必要があるためです。

これを行うためのよりクリーンな方法はありますか？

チェックされた例外をスローすることになっているメソッドのバイトコードを書くことが可能であれば？

たとえば、次のJavaクラスは、チェックされた例外をスローすることをメソッドが宣言しない限り、コンパイルされません。

次のScalaの同等物はそうですが（Scalaは例外をチェックしていないため）：

生成されたバイトコードがほぼ同じであっても、次のようになります。

質問：そのメソッド内のコードがそれを処理しない場合でも、チェックされた例外をスローすることをマークしないバイトコードを生成することは可能ですか（そしてどのように）？

私は次のことを研究しました。ただし、チェックされていない例外を除いて、コンパイラーはクライアント・プログラマーに例外をキャッチするか、throws節で宣言するように強制しません。実際、クライアントプログラマーは、例外がスローされる可能性があることさえ知らない場合があります。たとえば、StringIndexOutOfBoundsExceptionStringのcharAt()メソッドによってスローされます。

それはどういう意味ですか？

そのコードによると、コードにtry catchブロックを入れる必要はありませんが、コンパイラーがコードをtrycatchブロックに入れるように強制するのを見てきました。

私は彼らが正確に何であるか非常に混乱していますか？

RuntimeException非例外をキャッチする必要性をJavaで取り除く可能性はありますか? 多分コンパイラフラグ？

キャッチが促進される理由はわかっていますが、要件を強制するシンプルでストレートなツールを実行したいと考えています。そのため、何か問題が発生した可能性がある場合、追いつくのは好きではありませんが、意味のある例外でクラッシュしてアプリケーションを終了します。通常、これは次のようになります。

これにより、4 行のコードがごちゃごちゃになり、RuntimeExceptionエラー出力のラッピングがごちゃごちゃになります。場合によっては、何かを大きなブロックで囲むように人々を動機付けることさえありtry ... catch (Throwable ..)ます。これが、最愛の「不明なエラーが発生しました」アラート ボックスの原因である可能性があります...

いくつかの I コードをリファクタリングしようとして、次のように catch 句で例外をスローしようとしました -

ただし、「throw exception」行で例外をスローしようとすると、コンパイラーは、throw 句を新しい try/catch で囲む必要があるというメッセージで不平を言いました。

コンパイラがこれを必要とする理由と、それが提供する用途は何ですか?

ありがとう

Joshua Bloch は「Effective Java」で次のように述べています。

回復可能な条件にはチェック例外を使用し、プログラミング エラーには実行時例外を使用します (第 2 版の項目 58)。

これを正しく理解しているかどうか見てみましょう。

チェックされた例外についての私の理解は次のとおりです。

1. 上記はチェック済み例外と見なされますか?

2. RuntimeException は非チェック例外ですか?

未チェックの例外についての私の理解は次のとおりです。

4. さて、上記のコードもチェック済み例外ではないでしょうか? このような状況を回復しようとすることができますか? できますか？（注：私の3番目の質問はcatch上記の中にあります）

5.なぜ人々はこれを行うのですか?

なぜ彼らは例外をバブルアップさせたのですか? エラー処理は早いほうがいいのではないですか? なぜ泡立つのですか？

6. 正確な例外をバブルアップするか、Exception を使用してマスクする必要がありますか?

以下は私の読書です

Java では、いつチェック済み例外を作成し、いつ実行時例外にする必要がありますか?

チェックされた例外とチェックされていない例外をいつ選択するか

Java のいくつかのメソッドは、NoSuchElementException、IllegalArgumentException などの例外をスローします。しかし、これらのメソッドを使用すると、これらの例外はチェックされていないように見えます。つまり、メソッドの呼び出し元は、これらの例外をスローするメソッドで try/catch を実行する必要はありません。デフォルトでは例外は「チェック」されており、エラーのみが「チェックされていない」ものであるようです。しかし、どういうわけか、私がスローした例外もチェックされていません。それは変だね。

メソッドが例外をスローしたときに、呼び出し元がコンパイル時に例外をキャッチする必要があることを確認するにはどうすればよいですか? 簡単に言うと、どうすればチェック例外をスローできますか?

ありがとう！

throws 句でチェック済み例外を宣言したり、scala の try/catch ブロックでそれらを処理したりする必要がないことは、私が気に入っている機能です。ただし、例外を処理する必要があるのに無視された場合、問題になる可能性があります。チェックされた例外を無視するメソッドを見つけるためのツール (おそらくコンパイラ フラグ/プラグイン) を探しています。

要求されたレコードが存在しない場合、または呼び出し元が許可されていないためにアクセスできない場合に、多くの場所でnullを返すレガシーサービスレイヤーを使用するプロジェクトで作業しています。IDからリクエストされた特定のレコードについて話しています。たとえば、次のようなものです。

最近、このAPIを変更するか、代わりに例外をスローする新しいAPIを追加するようにプッシュしました。チェックされた例外とチェックされていない例外についての議論が続いています。

JPA / Hibernateなどの設計者からのメモをとって、チェックされていない例外が最も適切である可能性があることを提案しました。私の主張は、APIのユーザーがこれらの例外から回復することを合理的に期待することはできず、99％の場合、エラーが発生したことをアプリケーションユーザーに通知することができます。

ランタイム例外を一般的な処理メカニズムまで伝播させることで、エッジケースの例外の処理に伴う複雑さと必要なブランチ処理の多くが明らかに軽減されます。しかし、そのようなアプローチを取り巻く多くの懸念があります（当然そうです）。

JPA / EJBやHibernateなどのプロジェクトの設計者が、チェックされていない例外モデルを選択したのはなぜですか？それには非常に正当な理由がありますか？長所/短所は何ですか。これらのフレームワークを使用している開発者は、アダプターラッパーなどを使用して、スローされた場所の近くでランタイム例外を処理する必要がありますか？

これらの質問への回答が、私たち自身のサービスレイヤーに関する「正しい」決定を下すのに役立つことを願っています。