3

アプリケーションのレイアウトは次のとおりです。

WCF - ビジネス レイヤー クラス ライブラリ dll - データ アクセス レイヤー クラス ライブラリ dll - SQL Server。

通常、クラス ライブラリは DB 以外の外部リソースにはアクセスしません。

WCF レイヤーは、レポートのデータを提供します。

例外を上位レベルで処理する必要があるといういくつかのガイダンスを見たので、これは、クラス ライブラリに例外をスローさせるだけでよいので、クラス ライブラリで try catch ステートメントをまったく必要としないことを意味すると思います。

例外をキャッチしてライブラリに特定の情報を記録する必要はないと感じており、この場合は WCF レイヤーであるアプリ/クライアント コードで例外をキャッチする予定です。 WCF 例外処理戦略

このレベルでは、例外/スタック トレースをログに記録し、ユーザー フレンドリーな例外を提示する予定です。

WCF レベルでスタック トレースをログに記録すると、問題の原因を特定するのに十分な情報が得られると思います。

これはOKなアプローチですか、それとも何か見逃していますか

シンプルに保ち、不要な try キャッチを避け、例外/ログを 1 つの場所でのみ処理したいと考えています。

4

2 に答える 2

4

Eric Lippertは、例外処理に関する優れた記事を書いています。ぜひご覧ください。

あなたが絶対に何かをすることができない限り、あなたはそれを避けるために何か他のことを試みることができるようにあなたはどんな例外も捕まえるかもしれません。それを回避する方法がない場合は、finallyブロックで最高のものを期待しましょう。それ以外の場合、私見では、サービスを実際に消費するものが「わからない」ため、例外をバブルアップしてそこで処理するのが最善です。したがって、サービスは例外をバブルアップしてエンドユーザーに許可すると思います。誰もがこれらを同じように扱うわけではないので、それをどうするかを決定します。

繰り返しになりますが、現在URLが見つからないEric Lippertのブログから、次のようなコードを作成するのが最適です。

if (someUncoverableCondition)
    throw new SomeSpecificException();

可能なすべての例外をキャッチしようとするよりも。

最後に、できることと処理方法を知っていることを処理し、他の例外を発生させます。おそらくしばらくすると、コードをリファクタリングできるように、これらの例外を効率的に処理する方法がわかるようになります。一方、それらを通過させたほうがよいと思われる場合は、それがあなたの状況で正しいことであるに違いありません。

これがさらに読むことです。

例外処理の悪い習慣（おそらく直接関係はありませんが、とにかく知っておくとよいでしょう）

于 2012-11-23T17:43:58.930 に答える