私はC＃ライブラリを作成しています。このライブラリは、DLL後で他のアプリケーションのコードで使用されます。
ライブラリに、などの例外をスローする可能性のあるステートメントがある場合System.IO.IOException、それ自体をキャッチする必要がありますか、それともそれを使用するアプリケーションのプログラムによってキャッチされるように残す必要がありますか？
私はこれを尋ねます、なぜなら私は私の図書館で例外を捕まえていなかったからです。（ライブラリを使用する）アプリケーションをデバッグすると、VisualStudioはライブラリ内の未処理の例外としてアプリケーションを表示します。しかし、私がする> Continueと、プログラムは続行され、例外はアプリケーションによってキャッチされます。正常に動作しているようです。
さて、これを行っても大丈夫ですか？つまり、アプリケーションがデプロイされたときに問題が発生する可能性がありますか？それとも、それは絶対にライブラリ自体に捕らえられるべきですか？それとも、MSDNはどこかで、これよりも優れたものを「ベストプラクティス」として提案していますか？
良い図書館を書くことは芸術と科学です。提供される機能をすでに決定し、関連するAPIをライブラリの利用者に公開していると仮定すると、1つの問題、つまり例外処理が未解決のままであるように思われます。
一般に、ライブラリコードの実行中に発生する例外は、次の2つのグループに分けることができます。1。ライブラリの実装と機能に依存します。2.消費者またはシステムに依存し、ライブラリの関心領域外。
IMHOのベストプラクティスは、ライブラリコードによってスローされるすべての例外を定義し、それらをApplicationExceptionlib固有のプレフィックス（：<LibShortName>FormatExceptionまたは<LibShortName>InvalidOperationException。）を使用して関連する.NET例外から派生させることです。次に、ライブラリがクライアントコードに例外をスローする必要がある場合は、ライブラリから派生した例外を使用します。
ライブラリの外部で発生した例外があり、それらがライブラリ機能の観点から意味がある場合は、それらをキャッチして、すでにキャッチされた例外を内部例外として含む新しいライブラリ例外をスローするか<LibShortName>AggregateException、クライアントに公開する前に例外のチェーンを作成するために使用できます。
上記のスキームは、多くの一般的な.NETライブラリ（SharpSkia）で使用されています。この問題には他にもアプローチがありますが、上記のアプローチは図書館の利用者にとって最も有益であると思います。彼らはエラーに関するできるだけ多くの情報を入手します。さらに、例外のキャッチと処理にタイプベースのパターンを簡単に使用できます。
優れたライブラリを作成する上で最も重要な側面の1つは、パフォーマンスです。ライブラリに最適なものを取得するには、コード内の制御フローに例外を使用しないでください。例外は、エラー状態にのみ使用する必要があります。上記のパターンに違反する悪いデザインの良い例の1つは、ANTLR C# parser framewrokAFAIRv2でした。ある段階で、ライブラリは解析ロジックを制御するために例外を使用していましたが、これは非常に非効率的でした。その後、エラー状態に対してのみ例外を使用するようにリファクタリングされ、パフォーマンスが数桁向上しました。
最後に、.NETライブラリAPIの設計に関する最高の本の1つは次のとおりです。
興味深いAPI Reviews読み物は、.NET Core corefxリポジトリからのクローズドおよびオープンの問題と、少し古いがまだ古典的なものである、General APIDesignでタグ付けされたKrzysztofCwalinaブログ投稿に関するディスカッションです。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加