好吧,在这种情况下存在“标准”异常和“自定义”异常(FaultContact
由服务开发人员定义为 s 并出现在服务合同参考中的那些)。
在第一种情况下,我想你的担忧是CommunicationException
和TimeoutException
;这些记录了(模型的基础ICommunicationObject.BeginOpen
)和其他“打开”方法的可能例外情况。记录了“关闭”方法。还有用于发送消息的方法,例如. 在可能的更多中,这些应该是可发现的。ICommunicationObject
CommunicationObjectFaultedException
QuotaExceededException
IRequestChannel.Request
值得注意的是,从上面链接的 MSDN 文章中,是这样的:
通道抛出的所有异常必须是
System.TimeoutException
、System.ServiceModel.CommunicationException
或派生自 CommunicationException 的类型。(也可能抛出 ObjectDisposedException 等异常,但仅表明调用代码误用了通道。如果正确使用了通道,则必须只抛出给定的异常。)
然后是“故障”,这是在服务端引发的异常,并且(可能,如果启用)向调用者详细说明,然后调用者可以处理该异常或抛出正确的客户端异常:
在产生故障时,自定义通道不应该直接发送故障,而是应该抛出异常,并由上层决定是否将该异常转换为故障以及如何发送。
该频道State
提供了一个事件Faulted
,您可以订阅该事件,以便在它达到这种状态时得到通知,并可能采取行动。默认情况下(不配置抑制(?))错误将作为托管异常引发;再次重申:
在 WCF 客户端中,客户端应用程序感兴趣的通信期间发生的 SOAP 错误将作为托管异常引发。虽然在任何程序的执行过程中都可能发生许多异常,但使用 WCF 客户端编程模型的应用程序可以期望处理作为通信结果的 [...] 两种类型的异常。
这又是指上面提到的CommunicationException
和TimeoutException
。
最后,至少现在是出乎意料的:
FaultException
当侦听器收到操作合同中未预期或未指定的错误时,将引发异常;这通常发生在调试应用程序并且服务将
System.ServiceModel.Description.ServiceDebugBehavior.IncludeExceptionDetailInFaults
属性设置为 true 时。