一部の開発者が Java のチェック例外に反対するのはなぜですか?

チェック例外に対する異議

私は何年もの間、「なぜ一部の開発者はチェック例外にそれほど反対しているのか」という質問に対してまともな返答を得ることができませんでした。異常を確認しましたか？私は何度も会話を交わし、ブログ投稿を読み、ブルース・エッケルの視点を読みました（彼は私がこれに反対する声を上げたのを初めて見た人です）。

私は現在、いくつかの新しいコードを書いており、例外の処理方法には細心の注意を払っています。 「チェック例外は好きではない」という人々の意見を理解しようと努めていますが、まだ理解できません。

これまでの会話はすべて、答えのない同じ質問で終わりました...これを設定してみましょう:

一般的に言えば (Java の設計により)、

• 絶対に捕捉すべきではないエラー (VM はピーナッツアレルギーで、誰かがピーナッツの瓶を注いだ)
• RuntimeExceptionプログラマが間違ったことをした場合に使用されます (プログラマが配列の端から出て行った)。
• 例外 (RuntimeException を除く) プログラマが制御できない場合に使用されます (ファイル システムへの書き込み中にディスクがいっぱいになり、プロセスのファイル ハンドルの制限に達したため、これ以上ファイルを開くことはできません)
• Throwable は、すべての例外タイプの親クラスにすぎません。

例外が発生した場合、開発者ができることはプログラムを終了することだけだという意見をよく聞きます。

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

「やめただけ」という議論に関して、私が言いたいのは、たとえやめたとしても、それなりのエラーメッセージを表示する必要があるということです。エラー処理を回避するだけであれば、理由が明確に示されないままプログラムが終了したときに、ユーザーはあまり満足しないでしょう。

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

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

誰も答えない質問は次のとおりです。

代わりに RuntimeException
サブクラスをスローする場合Exception
サブクラスでは、
何をキャッチすべきかをどうやって知ることができますか?


答えが Exception をキャッチすることである場合、あなたもそれは間違っているように思えます

システム例外を同じ方法で処理する場合。スロー可能な場合、システム例外と VM エラー (など) を同じ方法で処理していることになります。それは私には間違っているように思えます

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

。

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

では、チェック例外が好きではない場合、その理由を説明できますか?そして、その答えのない質問に答えてください？

どちらのモデルの使用についてのアドバイスも求めていません。人々が Exception ではなく RuntimeException から拡張する理由と、例外をキャッチして再スローする理由を探しています。 1 つは、RuntimeException スローをメソッドに追加する代わりに。チェック例外を好まない理由を理解したいと思います。

以上が一部の開発者が Java のチェック例外に反対するのはなぜですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。