MethodAはMethodBを呼び出し、MethodBはMethodCを呼び出します。

MethodBまたはMethodCには例外処理はありません。ただし、MethodAには例外処理があります。

MethodCでは、例外が発生します。

現在、この例外はMethodAにバブリングされており、適切に処理されます。

これの何が問題になっていますか？

私の考えでは、ある時点で呼び出し元がMethodBまたはMethodCを実行し、それらのメソッドで例外が発生した場合、それらのメソッド内で例外を処理することで得られるものは、本質的にletではなくtry / catch / finallyブロックですそれらは呼び出し先までバブルアップしますか？

例外処理に関するステートメントまたはコンセンサスは、それだけで実行が継続できない場合にスローすることです-例外。わかった。しかし、try / catchブロックを完全にダウンさせるのではなく、チェーンのさらに上で例外をキャッチしてください。

リソースを解放する必要があるときに理解しています。それはまったく別の問題です。

一般的な原則として、例外の処理方法がわからない限り、例外をキャッチしないでください。MethodCが例外をスローしたが、MethodBがそれを処理するための有用な方法を持たない場合、例外がMethodAまで伝播できるようにする必要があります。

メソッドにcatchおよびrethrowメカニズムが必要な唯一の理由は次のとおりです。

• ある例外を、上記の呼び出し元にとってより意味のある別の例外に変換する必要があります。
• 例外に追加情報を追加する必要があります。
• リソースがないとリークするリソースをクリーンアップするには、catch句が必要です。

そうしないと、間違ったレベルで例外をキャッチすると、呼び出し元のコード（および最終的にはソフトウェアのユーザー）に有益なフィードバックを提供せずに、暗黙的に失敗するコードが発生する傾向があります。例外をキャッチしてすぐに再スローするという代替手段は無意味です。

これは何が問題なのですか？

何もない。

現在、この例外はMethodAにバブリングされており、適切に処理されます。

「適切に処理する」ことが重要な部分です。これが、構造化例外処理の核心です。

コードが例外を使用して「有用な」何かを実行できる場合は、それを実行します。そうでない場合は、おまかせください。

。。。try / catchブロックを完全にダウンさせるのではなく、チェーンの上位で例外をキャッチしてください。

それがまさにあなたがすべきことです。ハンドラー/リスローアーが「最後まで」あるコードを読んでいる場合、かなり悪いコードを（おそらく）読んでいることになります。

悲しいことに、一部の開発者は、キャッチブロックを、作成するすべてのメソッドにスローする「ボイラープレート」コードと見なします。その例外は、プログラムを「エスケープ」して強制終了することはありません。

ここでの難しさの一部は、ほとんどの場合、例外が常にスローされているわけではないため、この問題が気付かないことです。しかし、例外が発生すると、プログラムは非常に多くの時間を無駄にしコールスタックの選択を徐々に解除して、実際に例外に役立つ何かを実行する場所にたどり着くまでの努力。

ライブラリとアプリケーションを区別する必要があります。

ライブラリはキャッチされない例外を自由にスローできます

ライブラリを設計するとき、ある時点で何がうまくいかないかを考えなければなりません。パラメーターの範囲が間違っているかnull、外部リソースが利用できないなどの可能性があります。

あなたのライブラリは、ほとんどの場合、賢明な方法でそれらに対処する方法を持っていません。唯一の賢明な解決策は、適切な例外をスローし、アプリケーションの開発者にそれを処理させることです。

アプリケーションは常にある時点で例外をキャッチする必要があります

例外がキャッチされると、それらをエラーまたは致命的なエラーのいずれかに分類したいと思います。通常のエラーは、アプリケーション内の単一の操作が失敗したことを意味します。たとえば、宛先が書き込み可能ではないため、開いているドキュメントを保存できませんでした。アプリケーションが行うべき唯一の賢明な考えは、操作が正常に完了できなかったことをユーザーに通知し、問題に関して人間が読める情報を提供し、ユーザーに次に何をすべきかを決定させることです。

致命的なエラーは、メインのアプリケーションロジックから回復できないエラーです。たとえば、ビデオゲームでグラフィックスデバイスドライバーがクラッシュした場合、アプリケーションがユーザーに "優雅に"通知する方法はありません。この場合、ログファイルを作成し、可能であれば、何らかの方法でユーザーに通知する必要があります。

このような深刻な場合でも、アプリケーションはこの例外を有意義な方法で処理する必要があります。これには、ログファイルの書き込み、クラッシュレポートの送信などが含まれる場合があります。アプリケーションが何らかの方法で例外に応答しない理由はありません。

説明するパターンの何が問題なのかというと、メソッドAには3つのシナリオを区別する方法がないためです。

1. 方法Bは予期された方法で失敗しました。

2. 方法Cは、方法Bでは予期されなかった方法で失敗しましたが、方法Bは安全に破棄できる操作を実行していました。

3. 方法Cは、方法Bでは予期されなかった方法で失敗しましたが、方法Bが、Cの失敗のためにBがクリーンアップに失敗したと思われる一時的なインコヒーレント状態にする操作を実行していました。

メソッドAがこれらのシナリオを区別できる唯一の方法は、Bからスローされた例外にその目的に十分な情報が含まれている場合、またはメソッドBのスタックアンワインドによりオブジェクトが明示的に無効化された状態のままになる場合です。残念ながら、ほとんどの例外フレームワークは両方のパターンを扱いにくくし、プログラマーに「より悪い」設計上の決定を強いることになります。