新しい例外をスローすることは技術的にコストがかかりますが、「コストがかかる」というのは相対的なものであるため、大きな議論はしません。1分間に100個のそのような例外をスローする場合、コストは表示されない可能性があります。このような例外を1秒間に1000回スローすると、パフォーマンスが低下する可能性があります（したがって、ここで説明する価値はありません。パフォーマンスが重要です）。
なぜこのアプローチが使われているのか、私は尋ねなければならないと思います。例外がスローされる可能性のあるすべてのレベルで意味のある例外情報を追加できるというのは本当に本当ですか。もしそうなら、その情報は次のようになるということも本当ですか。
- 実際にユーザーと共有したいことはありますか？
- ユーザーが解釈、理解、使用できるものはありますか？
- 低レベルのコンポーネントの後での再利用を妨げないように書かれていますが、それらが書かれたときにその有用性がわからない可能性がありますか？
あなたの例では、データベースでの認証に問題があったことをユーザーに通知することから人工スタックが開始されるため、ユーザーとの情報の共有について質問します。潜在的なハッカーにとって、それは操作が何をしていたかについて何かを明らかにする良い情報です。
カスタム例外スタック全体を返すことに関しては、ほとんどの（正直な）ユーザーにとって役立つものではないと思います。たとえば、顧客名のリストを取得するのに問題がある場合、データベースでの認証に問題があったことを（ユーザーとして）知るのに役立ちますか？統合認証を使用していて、各ユーザーがアカウントを持っていて、システム管理者に連絡して、アカウントに特権がない理由を確認する機能がない限り、おそらくそうではありません。
まず、スローされたFramework例外と、ユーザーに提供したい例外メッセージとの間に実際に意味上の違いがあるかどうかを判断することから始めます。存在する場合は、先に進み、最下位レベルでカスタム例外を使用します（この例では「ログインに失敗しました」）。その後の手順では、例外が実際に表示されるまで、カスタム例外は実際には必要ありません。関心のある例外はすでに生成されています（ログインに失敗しました）。コールスタックのすべてのレベルでそのメッセージをラップし続けることは、ユーザーにコールスタックを公開する以外の本当の目的にはなりません。これらの「中間」ステップでは、try / catchブロックが適切に配置されていると仮定すると、単純な「ログアンドスロー」戦略が適切に機能します。
ただし、実際には、この戦略には別の潜在的な欠陥があります。それは、実装されたカスタム例外標準を維持する責任を開発者に強いることです。低レベルの型を作成する場合、呼び出し階層のすべての順列を知ることはできないため（「クライアント」はまだ作成されていない可能性があります）、すべての開発者（または1人の開発者）がラップしてカスタマイズすることを覚えている可能性は低いようです。すべてのコードブロックのエラー状態。
私は通常、下から上に向かって作業するのではなく、プロセスのできるだけ遅い段階（つまり、呼び出しスタックの「最上位」にできるだけ近い場所）でスローされた例外が表示されることを心配しています。通常、アプリケーションの低レベルでスローされた例外のメッセージを置き換えようとはしません。特に、これらの低レベルのメンバーの使用は、呼び出しが深くなるほど抽象化される傾向があるためです。私は、ビジネス層以下で例外をキャッチしてログに記録し、プレゼンテーション層でそれらをわかりやすく表示する傾向があります。
例外処理のベストプラクティスに関するいくつかの適切な記事を次に示します。
http://www.codeproject.com/KB/architecture/exceptionbestpractices.aspx
http://aspalliance.com/1119
うわあ、これは言葉になりました...事前にお詫びします。