サービス実装でCommunicationExceptionsおよび/またはTimeoutExceptionsを処理する必要がありますか？ （クライアントに加えて？）。クライアントがタイムアウトするとどうなりますか？サービスがメッセージの処理を続行するか、例外がスローされますか？例えばCommunicationExceptionsはWCFのサーバー側で処理する必要がありますか？
おかげ
-Vic
は、私は次の操作を実行する必要がありますか？
public MyServiceImpl:IMyService
{
void DoSomething()
{
try{
//Do something
}
catch (Communication exception){}
catch (Timeout exception){}
}
}
}
あなたはコールバックのシナリオではないですので、タイムアウトがあるかどう（それはあなたの方法はありません前にメッセージを取得し、様々なディスパッチャによってcatchedされるため）、サービス・メソッドも呼び出されません。したがって、ここでこれらの例外をキャッチする必要はありません。
操作のパラメータの1つとしてStreamを使用している場合は、クライアントがひっそりとした場合にストリームを読み込み中に例外が発生する可能性があるため、少し異なります。しかし、その場合は、とにかく例外を守る必要があります。通常通り
：それは
:-)によって異なりますが、コールごとのインスタンス化、または一方向のメッセージを持っている場合は悪いことで（例外）は、サーバー上で発生した場合でも、その後、彼らはなるだろうクライアントに伝播される（または一方向のシナリオ：ちょうど落とされた）、それほど心配する必要はありません。
ただし、セッションシナリオがある場合は、トランスポートプロトコル（netTtcpバインディングの場合はTCP/IP）でトランスポートセッションが使用されます。 wsHttpBindingはサーバーとのアプリケーションセッションを確立し、サーバー上ですべての例外をキャッチして処理し、SOAP障害としてのみ返すようにする必要があります。
そうしないと、チャネル（クライアントのプロキシインスタンスとサーバーインスタンスの間の通信パイプ）が「フォールト」になります。クライアントプロキシインスタンスを再作成する必要があります。
また、.NETの例外は.NET固有のものであることに留意してください。あなたのサービスが相互運用可能で、例えば、 Java、Ruby、PHPまたは他のクライアントの場合、サーバー側ですべての.NET例外を捕捉し、SOAP障害（相互運用可能な同等物）に変換する必要があります。これを行うには、サーバー側にIErrorHandlerインターフェースを実装します。
マーク