WCF入门(七)——异常处理1
首先以一个简单的例子演示一下远程调用发生异常的结果:
服务器端代码如下:
[ServiceContract] public interface IService1 { [OperationContract] void ErrorTest(); } public class Service1 : IService1 { public void ErrorTest() { throw new InvalidOperationException("异常测试"); }
该服务非常简单,直接抛一个异常。当运行客户端代码触发这个异常时,客户端会接收到如下异常:
从中我们可以看到:虽然服务器端抛出的是InvalidOperationException异常,但是客户端接收到的却是FaultException异常。从WCF测试客户端的传递的消息中也可以看出这一点。
WCF异常处理机制
-
通讯异常,这通常是因为链路的原因,比如服务没有启动,网络阻塞等。通常是CommunicationException或者其派生类
-
超时异常,这类异常是因为操作时间超时,超时时会抛出 TimeoutException。
-
服务异常,由服务端根据具体的业务逻辑触发,当业务逻辑抛出异常时,会将其封装成FaultException抛给客户端。
通信异常和超时异常是由WCF框架所产生的,由于网络原因,它们出现是正常的,因此也被称为预期异常,是正常调用的时候需要处理的异常。而FaultException异常则是业务逻辑中异常情况时出现的异常,是由自己实现的代码中产生的,是非预期的异常。具体处理方式根据业务逻辑而定。
但值得注意的是:服务被设置为PerSession模式或者Single模式,服务异常还会导致服务对象被释放而终止服务。(这个是在网上看到的说明,但我自己试的时候没有挂,从WCF服务对象模型上来分析也不应该会挂,也没有看到MSDN上哪儿有写,待后续确认后再更新)
至于为什么要将CLR异常封装成FaultException后抛出,我的理解是:对于异常信息,是序列化后才发布给客户端的,也就是说,客户端也 得需要理解这个异常才能反序列化异常信息。因此,客户端必须知道异常的格式,由于WCF的客户端并非只有.net语言才能实现,因此需要发布异常格式,由 于CLR的异常比较多,加上还有自定义异常,无法公布所有异常格式,因此,将其统一成FaultException发布,这样客户端才能顺利解析。
了解了这个后,我们就知道InvalidOperationException异常为什么会变成了FaultException异常,但是存在的一个问题是:虽然客户端能感知到调用服务发生了异常,但仍然不知道异常信息,有时无法进行进一步处理。
Debug期间异常信息传递
在前面的异常信息中就有说明:有关该错误的详细信息,请打开服务器上的 IncludeExceptionDetailInFaults (从 ServiceBehaviorAttribute 或从 <serviceDebug> 配置行为)以便将异常信息发送回客户端。它告诉了我们有两个方式可以传递这个异常信息:
-
配置serviceBehaviors,将includeExceptionDetailInFaults设置为true
-
在服务上的ServiceBehaviorAttribute里面设置IncludeExceptionDetailInFaults
这两种方式是等效的,不过建议在配置文件里面使用,统一设置比较方便,也方便统一关闭。
经过这个设置后,再运行客户端代码,这次就可以看到异常信息了:
连异常的调用栈也能看到,方便我们进行异常定位。
<StackTrace> 在 WcfService.Service1.ErrorTest() 位置 Service1.cs:行号24
在 SyncInvokeErrorTest(Object , Object[] , Object[] )
不过,这个在另一方面也暴露了服务器的信息,对于这种网络程序来说是不安全的,因此只建议在Debug的时候使用,从serviceDebug的名字中也可以看出这一点。
构造FaultException
为了安全,前面所说的异常信息获取方式,只能在Debug期间使用,那么,对于Release版本,则需要我们自己手动把运行异常封装成FaultException返回。
public class Service1 : IService1 { public void ErrorTest() { try { throw new InvalidOperationException("异常测试"); } catch (Exception e) { throw new FaultException(e.Message); } } }
这次我们就能获取到异常信息了。
对于比较复杂的异常信息,可以自己构造一个FaultException<T>,如下是一个简单的示例:
[ServiceContract] public interface Iservice { [OperationContract] [FaultContract(typeof(DataAccessFault))] void Operation(); } public class Service : Iservice { public void Operation() { try { // Access database … } catch (DbException e) { DataAccessFault fault = new DataAccessFault(); fault.AdditionalDetails = e.Message; throw new FaultException<DataAccessFault>(fault); } } }
自己手动构造FaultException的方式比较麻烦,需要在每一个提供的接口中都捕获异常,并重新封装抛出,一来不好看,处理起来也比较麻烦。由于篇幅有限,下篇文章中介绍一个更为简单的方法。