呼び出し元のメソッドで例外を処理したい場合は、メソッドの例外を宣言できることはわかっています。これにより、外側のメソッドが IOException をスローした場合に、コードを try/catch ブロックにラップせずに、OutputStream への書き込みなどを行うこともできます。
私の質問は次のとおりです。現在のメソッドの代わりに呼び出し元のメソッドで例外を処理したい場合に、これが通常行われるインスタンスを誰でも提供できますか?
編集：最後の行でスーパークラスの代わりにメソッドを呼び出すことを意味しました。
一般に、実際に適切なアクションを実行できるコードによって例外がキャッチされるように、例外フローを設計します。
これは通常、「ライブラリ」メソッド（または大規模なプロジェクトのある種の一般的なユーティリティメソッド）では、例外をキャッチせずにスローすることを意味します。
一方、実際にはほとんど発生しないと思われる例外をスローするメソッドを宣言している状況がある場合（たとえば、シリアル化には通常、実際には発生しないあらゆる種類のスプリアスチェック例外が含まれます。 Integerを逆シリアル化する場合、Integerクラスが存在しない可能性はほとんどありませんが、適切な例外をキャッチする必要があります）、RuntimeExceptionに再キャストする3番目のオプションがあります。
「スーパークラス」とは、メソッドを呼び出したコードを意味すると思います。
呼び出し元がメソッドと比較して問題についてより多くのことを知っていると予想される場合は、この責任を呼び出しスタックに渡すことができます。
一般に、問題の処理方法がわからない場合は、処理しないでください。イーサはそれを渡すか、別の例外でラップします。
その時点で適切な方法でエラーを処理できない場合(たとえば、エラー メッセージを表示する、別のパスを使用するなど)、問題が発生するのを待ちます。
アプリケーションの別のレベルでエラーを処理する場合。
半具体的な例を次に示します。一連の状態とアクションとして実装されている Web アプリケーションがあるとします。状態の処理中に、データベース アクセスによってSQLExceptionがスローされるとします。これは、アプリケーションの通常の操作中には発生しません。データベースに何か問題があった場合にのみ発生します。
データベースにアクセスするメソッドは、このような致命的なエラーを処理するための私の手順が何であるかを知る必要はありません。状態を処理するメソッド内のより高いレベルで実装されたそのロジックは、文字通りであるかどうかに関係なく、実行時エラーに対して本質的に同じですRuntimeException: 見栄えの良いエラー メッセージをユーザーに吐き出して、技術サポートに連絡するように伝えます。 .
このロジックを実行するtry/catchブロックを、データベースにアクセスし、おそらく. それが と呼ばれるものです。SQLExceptionnightmare
アプリケーションのアーキテクチャ レイヤー間で情報を転送する一環として、期待値を使用してきました。
例:
DAO (データベース アクセス レイヤー) が SQLException を取得すると、カスタマイズされた DAOLayerException がスローされます。これはビジネスレイヤーによってキャッチされ、プレゼンテーション レイヤーによってキャッチされる例外がスローされます。
これは未チェックの例外用でした。
関数が多数の呼び出し元によって使用される場合、または関数の開発時に不明な場合、私は通常、チェックされていない例外をスローする (それらを処理しない) という慣行に従います。
あなたは例を求めました、そしてここに一般的なものがあります。
特定のファイル形式を読み取るコードを記述している場合、これらは通常IOExceptionを宣言します。これは、デスクトップアプリ（ダイアログボックスを表示したい）、テキストユーティリティ（エラーメッセージを書き込みたい）、またはWebアプリ（エラーコードを返したい）で使用される可能性があるためです。 。例外処理により、それを行うことができます。
Web フレームワーク (Spring など) では、多くの場合、エラーが伝播され、コンテナーがそれらを処理します (ユーザーにエラー ページまたはメッセージを表示する、トランザクションをロールバックするなどによって)。
また、OutOfMemoryError のように、キャッチできない Java エラーがたくさんあります。それらを捕まえることはできますが、適切に対処することはできません。