0

独自のConnectionクラスとConnectionStreamクラスがあり、基本的にはConnectionのsend/receiveメソッドをラップするだけです。

Connectionの送信/受信メソッドは、ServerClosedConnExceptionやNetworkShutdownExceptionなどの例外をスローする可能性があります

私のストリームがこれらをキャッチしてIOExceptionでラップする必要がありますか（innerExceptionを使用）、または単にユーザーにバブルさせることができますか（もちろん、クリーンアップを処理するためにいくつかの試行を行います）

.NET Frameworkで、NetworkStreamはソケットからのエラーをIOExceptionでラップします。

4

4 に答える 4

3

例外を処理するつもりがない限り、例外をキャッチしないでください。それらは、アップストリームハンドラーがそれらをキャッチして処理するか、プログラムが終了するまで、コールスタックをバブルアップします。

Connectionクラスがまたはのような非常に具体的な例外ServerClosedConnExceptionをNetworkShutdownExceptionスローしていて、それをキャッチしてあまり IOException具体的でない例外を再スローした場合、それがどのように値を追加しているかわかりません。

于 2013-02-08T22:59:10.523 に答える
2

追加する詳細がない場合、または自分で例外を処理できる場合を除いて、例外をバブルアップさせるのがベストプラクティスです。最初のケースでは、実際の例外を。として新しい例外をスローしますInnerException。

MSDNのラッピング例外をお読みください。

あなたの場合、私はそれをただ泡立たせます。

于 2013-02-08T22:59:41.020 に答える
2

Stream基本クラスは、そのサブクラスの事実上のコントラクトとして機能します。サブクラスをパブリックAPIで公開することを計画している場合、サブクラスのユーザーはその特定のタイプを幸いにも知らない可能性があるため、Streamクラスの文書化された動作に従うことを検討してください。たとえば、Readメソッドのコントラクトを順守したい場合は、実装でhttp://msdn.microsoft.com/en-us/library/にリストされているタイプではない例外を公開しないでください。 system.io.stream.read。

ただし、これは、より具体的な例外タイプを使用できないことを意味するものではありません。とにかくカスタム例外タイプを作成する理由がある場合（JerKimballが言及した設計ガイドラインを読んだ後、これが良い考えだと思うと仮定して）、それはIOExceptionのサブクラスである可能性があります。ただし、Streamサブクラスのユーザーが、例外の詳細を使用してロギング以外のことを実行する可能性が高い場合を除いて、これはおそらく必要ありません。

于 2013-02-08T23:14:26.290 に答える
1

例外ガイドラインの内容は次のとおりです。

[参照]

最も関連性の高い部分：

Do throw the most specific (the most derived) exception that is appropriate. 
For example, if a method receives a null (Nothing in Visual Basic) argument, 
it should throw System.ArgumentNullException instead of its base type 
System.ArgumentException.

あなたの場合も意味するように、最も詳細な例外は、伝播する「正しい」例外であると推定します。例外タイプについていくつかの仮定を行うと、それらはおそらく「ConnectionException」カスタム例外にラップされた、伝播する「正しい」ものです。

IOExceptionそうは言っても、それを例外の「形」であるため、それをで囲むことを検討することがどのように「理にかなっている」かはわかります。しかし、私がガイドラインに同意せず、自分の道を進んだ場合、それは通常、後で私を噛みます。:)

于 2013-02-08T22:55:25.353 に答える