問題タブ [checked-exceptions]

Java (またはチェック済みの例外を持つ他の言語) で、独自の例外クラスを作成する場合、チェックするかチェックしないかをどのように決定しますか?

私の本能は、チェックされた例外は、呼び出し元が生産的な方法で回復できる可能性がある場合に呼び出されると言うのですが、チェックされていない例外は回復できない場合に多くなりますが、他の人の考えに興味があります。

私はJavaでこのファクトリメソッドを持っています:

そして、2 つのチェック済み例外を非チェック済み例外に変換したいと考えています。これについて最善の方法は何ですか？

例外をキャッチし、キャッチした例外を内部例外として使用して新しい RuntimeException をスローする必要がありますか?

これを行うためのより良い方法はありますか、それとも最初からこれを試みるべきですか?

編集：
明確にするために。これらの例外は致命的です。構成ファイルは基本的にプログラムの操作に関係しており、すべての例外はプログラムの最上位でキャッチされてログに記録されるためです。

私の目的は、工場を呼び出すすべてのメソッドのシグネチャに例外が追加され、不要なスロー例外を回避することです。

何年もの間、私は次の質問に対するまともな答えを得ることができませんでした: なぜ一部の開発者はチェック例外に反対するのでしょうか? 私は数多くの会話をしたり、ブログを読んだり、Bruce Eckel の発言を読んだりしました (彼らに反対する人を初めて見ました)。

現在、いくつかの新しいコードを作成しており、例外の処理方法に細心の注意を払っています。私は「私たちはチェックされた例外が好きではない」群衆の視点を見ようとしていますが、まだそれを見ることができません.

私が行ったすべての会話は、同じ質問に答えられずに終わります...設定させてください：

一般に (Java の設計方法から)、

• Error決して捕まえてはいけないもの用です（VMにはピーナッツアレルギーがあり、誰かがピーナッツの瓶を落としました）
• RuntimeExceptionプログラマーが間違ったこと (プログラマーが配列の最後を歩いた) のためのものです。
• Exception(例外RuntimeException) は、プログラマーの管理外のものです (ファイル システムへの書き込み中にディスクがいっぱいになり、プロセスのファイル ハンドルの制限に達し、それ以上ファイルを開くことができなくなります)。
• Throwableすべての例外タイプの単なる親です。

私がよく耳にする議論は、例外が発生した場合、開発者はプログラムを終了するだけだというものです。

私がよく耳にするもう 1 つの議論は、チェック済み例外によってコードのリファクタリングが難しくなるというものです。

「終了するだけです」という引数については、終了する場合でも、適切なエラー メッセージを表示する必要があると述べています。エラーを処理するだけなら、理由を明確に示さずにプログラムが終了しても、ユーザーはあまり満足しません。

「リファクタリングが難しくなる」群集にとって、これは適切なレベルの抽象化が選択されていないことを示しています。メソッドが をスローすることを宣言するのではなく、何が起こっているのかにより適した例外に変換する必要がありますIOException。IOException

Main をラップすることに問題はありませんcatch(Exception)(または、場合によってcatch(Throwable)は、プログラムが正常に終了できるようにするためです。ただし、必要な特定の例外を常にキャッチします。これにより、少なくとも、適切なエラーメッセージ。

人々が決して答えない質問はこれです：

RuntimeException サブクラスの代わりにサブクラスをスローする場合Exception 、何をキャッチする必要があるかをどうやって知るのでしょうか?

答えがキャッチの場合、Exceptionシステム例外と同じ方法でプログラマ エラーを処理しています。それは私には間違っているようです。

キャッチThrowableすると、システム例外と VM エラー (など) を同じ方法で処理します。それは私には間違っているようです。

答えが、スローされたことがわかっている例外のみをキャッチするというものである場合、どの例外がスローされたかをどうやって知るのでしょうか? プログラマー X が新しい例外をスローし、それをキャッチするのを忘れた場合はどうなりますか? それは私には非常に危険に思えます。

スタック トレースを表示するプログラムは間違っていると思います。チェック例外が嫌いな人はそう感じませんか？

では、チェック済み例外が気に入らない場合は、理由を説明し、回答されていない質問に回答していただけますか?

どちらのモデルをいつ使用するかについてのアドバイスを探しているわけではありません。私が探しているのは、人々が拡張するのRuntimeExceptionが好きではないために拡張するException理由、および/または例外をキャッチRuntimeExceptionしてメソッドにスローを追加するのではなく、再スローする理由です。 . チェック例外を嫌う動機を理解したい。

Javaでは、チェックされていない例外がtryブロックでキャッチされる可能性があると言われましたが、キャッチされた場合、それはチェックされた例外と呼ばれませんか？

重複の可能性:
チェックされた例外とチェックされていない例外をいつ選択するか

こんにちは！

そのため、チェック済みまたはチェックなしの例外をいつスローするかについては、まだ慣れています。この場合、他の人が最も適切だと思うものを知りたいです。

したがって、この場合、ユーザーが不正なデータを渡す状況から簡単に回復できないため、実行時例外をスローしたいと思います。渡されるデータを制御できないことを事前に指摘したいと思います。可能であれば、コンストラクターの条件が真であることを保証するインターフェイスを作成します。ただし、これは既に計算された相関のための便利なクラスであるため、ユーザーが正確な情報を提供していることを信頼する必要があります。

よし、みんなの感想聞かせて！

ランタイム例外を（チェックされている場合とは対照的に）チェックされていないことが理にかなっているのはなぜですか？

.NET では、メソッド シグネチャは、コードによってスローされる可能性のあるいくつかの例外の処理に失敗したかどうかを教えてくれません。HashTable remove を使用しているが、ArgumentNullException を処理していない場合、警告できるツールはありますか? 実行時に驚かせたくありません。

これは、コードを十分に理解する必要があるということでしょうか。

例外について読んでいると、チェックされた例外とチェックされていない例外に出くわします。

編集:例外クラスを作成するかどうかを知りたいのですが、チェック済みまたは未チェックとして作成するにはどうすればよいですか?

それぞれの意味は何ですか？

Java では、メソッドによってスローされるすべての例外をリストするようにプログラマーに強制しているため、コードのユーザーがスローされる可能性のあるすべての例外をリストする簡単な方法を作成していることを知っています。

一方、.NET にはそのような機能はなく、残っているのは API ドキュメントまたは XML ドキュメントだけで、例外がリストされていることもあります。

特定の呼び出しがスローする可能性のある例外を示す VS 用のアドオンはありますか? リフレクションの力を考えると、呼び出しを調べて、呼び出しを介して可能な実行のすべての分岐を調べ、スローされている .NET 例外をチェックすることは可能ではないでしょうか?

method1に例外をスローする例外をスローするmethod2例外チェーンがありmainます。何らかの理由で、コンパイラはエラーを処理するように強制し、処理しmethod2ない場合はエラーとしてマークし、チェックされた例外であることを示します。しかし、同じExceptionことが行のさらに下にスローされるmainと、コンパイラはそれを無視することを許可し、エラーを表示しません。

の元の例外method1は、ParseExceptionチェックされる です。しかし、メソッドthrows Exceptionにはヘッダーにジェネリック句があり、同じオブジェクトが同一の句を持つ method2 にスローされますthrows Exception。この例外は、コンパイラによってチェック/キャッチされた状態をいつ、どのように失いますか?

明確にするために編集：

編集： 申し訳ありませんが、質問は間違いに基づいていました... main メソッドには、実際throws Exceptionには欠落している節がありました。それを削除したところ、コードは期待どおりに動作するようになりました。助けてくれてありがとう！