仕様によれば、スローされる可能性のあるすべての例外をキャッチする必要がありますか?

これを実行しても例外が発生しないことがはっきりとわかっている場合もありますが、それでも例外をキャッチする必要がありますか?

場合によっては、トリガーされるエラーは致命的であり、ユーザーの操作によって引き起こされるものではありません。このままでは捕まえても死んでしまいます。このように、この例外をキャッチする意味は何でしょうか?

しかし、私はいつも、キャッチせずに投げて忘れてはいけないと言っている人をたくさん見かけます。

それではどうすればいいでしょうか？

返信内容:

これを実行しても例外が発生しないことがはっきりとわかっている場合もありますが、それでも例外をキャッチする必要がありますか?

場合によっては、トリガーされるエラーは致命的であり、ユーザーの操作によって引き起こされるものではありません。このままでは捕まえても死んでしまいます。このように、この例外をキャッチする意味は何でしょうか?

しかし、私はいつも、キャッチせずに投げて忘れてはいけないと言っている人をたくさん見かけます。

それではどうすればいいでしょうか？

個人的には、ある程度のエラー処理を把握する必要があると感じていますが、この程度を把握するのは非常に困難です。

私の理解は次のとおりです:

• まず第一に、基本的かつ必要な例外を設けなければなりません。

• 第二に、可能な限りすべての例外をキャッチする必要はありません。そうでない場合は

  • 長いエラー処理コード

  • 実行効率の問題

  • いくつかの例外が捕捉されましたが、それらに対処するより良い方法はありません。たとえば、それがコード内のバグである場合は、コード内のバグを可能な限り明らかにし、できるだけ早く解決する必要があります。 。

• 最後にまとめると、例外処理にはある程度の制御が必要です。その程度は次のとおりだと思います。

  • 基本的かつ必要な例外処理を実行します

  • 完璧を追求してすべての例外処理を意図的に実行しないでください。一部の問題はできるだけ早く明らかにして解決する必要があります。

私の経験:

処理されることがわかっている例外をキャッチし、プログラマーが手動で処理できるように他の例外をエラー記録します

1. 例外処理は階層的です。独自のモジュールを実装する場合は、依存するサードパーティ モジュールの例外処理を独自のモジュールに含めます
Java 例外処理の 10 のベスト プラクティス

しかし、ホイールを投げるように自分でセットを組み立てるのが好きな人は常にいますが、ピットから上がった後、他人が作ったホイールがとても良いことに気づきます（笑）。

例外をキャッチすることは、必ずしも死ぬことを意味するわけではありません。たとえば、ネットワーク上の理由でメールの送信が失敗した場合、この時点で例外をスローすると失敗します。再度処理するためにキューに入れられます。

プログラムをより堅牢にするための例外があります