、使用客户端或者通过对象调用操作,或者关闭基础客户端通道,都会在客户端应用程序中出现异常,WCF是基于网络的通讯服务,错误异常也是要基于消息传递的,在WCF中提供了一个错误消息处理的类FaultException...(无效的操作异常)) 通常没有有效的方法来处理意外错误,所以通产不应该在调用WCF客户端时捕获这些异常 2、预期异常:预期异常包括 (1)、TimeoutException (2)、CommunicationException... (3)、CommunicationException 的任何派生类 上面这些异常表明在通信的过程中出现问题,该问题可以通过终止WCF客户端并报告通信故障而得到安全的处理,因为外部因素可能导致任何应用程序中出现这些错误...,所以正确的应用程序必须捕获这些异常并在发生异常时进行恢复。...客户端接收到了服务器返回的除数不能为0的异常,然后抛出。 (2)、验证通讯超时的异常抛出,原理通过将连接后的时间设置为很小的值,那么服务端的运算肯定来不及,就会抛出超时的信息。
这是一个WCF相关的问题,我想99%的人都有可能会犯这样的错误——即使你对yield了解得非常透彻。闲话少说,我们通过一个简单的实例来说明这个问题。...如果category参数提供的字符串为Null或者是空字符串,抛出一个FaultException异常并提示“Invalid Category”,这样客户端在输入不合法参数的情况下可以得到错误消息。...return "Bar"; yield return "Baz"; } } 可是正常并不意味着正确,客户端其实根本无法得到服务端提供给它的错误消息,如下所示的是客户端调用服务时指定一个空字符串参数情况下得到的错误...一个CommunicationException异常被抛出来,得到的错误消息为“An error occurred while receiving the HTTP response to http:/...这貌似和我们预期的效果不一样,我们希望的是客户端抛出一个FaultException,并提示“Invalid category”。
在服务执行过程中,我们手工抛出FaultException异常,WCF服务端框架会对该异常对象进行序列化病最终生成Fault消息。...当WCF客户端框架介绍到该Fault消息之后,会做一项相反的操作:对Fault消息中进行解析和反序列化,重新生成并抛出FaultException异常。...WCF框架自动为我们作了这么多“幕后”工作,使得开发人员可以完全采用编写一般的.NET应用程序的模式进行异常的处理:在错误的地方抛出相应异常,对于潜在出错的方法调用进行相应的异常捕获和处理。...1: [Serializable] 2: public class FaultException : CommunicationException 3: { 4: //其他成员...MessageFormatter实现了在正常的服务调用过程中方法调用和消息之间的转换,但是,当异常(这里指的是FaultException异常)从服务端抛出,WCF通过需要一个相似的组件实现类似的功能:
而最终服务调用体现在消息的交换上,消息时基于XML的(除了少部分非XML的消息,比如JSON)。从数据转化的角度上讲,WCF起到了一个将数据从这两种形态数据进行转化和适配的作用。...先通过下面的代码片段来看看FaultException的基本定义: 1: [Serializable] 2: public class FaultException : CommunicationException...3、 FaultException 当从服务端抛出异常时,如果需要通过一个对象用于描述错误的消息信息,不管该对的类型是基元类型(比如String,Int等)还是自定义类型(比如自定义数据契约...在服务执行过程中,我们手工抛出FaultException异常,WCF服务端框架会对该异常对象进行序列化病最终生成Fault消息。...当WCF客户端框架介绍到该Fault消息之后,会做一项相反的操作:对Fault消息中进行解析和反序列化,重新生成并抛出FaultException异常。
服务端只有抛出FaultException异常才能被正常地序列化成Fault消息,并实现向客户端传播。...WCF内部是如何处理抛出的非FaultException异常的呢?...实际上,WCF对非FaultException异常的处理并不复杂,我们现在就来简单介绍一下相关的流程:在执行服务操作过程中,如果抛出一个非FaultException异常,WCF会先判断IncludeExceptionDetailInFaults...因此,在这种情况下,服务端抛出的信息总是能够原封不动地传递到客户端。而客户端捕获的总是一个泛型的FaultException异常。...同样以我们的计算服务为例,在Divide方法中我们直接用ExceptionDetail封装在运算过程中抛出的异常,最终抛出FaultException异常。
通过WCF基本的异常处理模式[上篇], 我们知道了:在默认的情况下,服务端在执行某个服务操作时抛出的异常(在这里指非FaultException异常),其相关的错误信息仅仅限于服务端可见,并不会被WCF...一、 通过FaultException直接指定错误信息 对于执行服务操作中抛出的异常,如果服务的定义者仅仅希望服务的调用者得到一段自定义的错误信息文本(字符串),我们要做的实际上很简单:在服务操作中直接抛出一个...虽然在很多情况下,在服务端指定服务操作的过程中直接抛出含有自定义错误信息的FaultException异常,就能过客户端感知到遇到的具体错误并进行必要的排错和纠错。...在《WCF技术剖析(卷1)》中,我们曾多次对契约进行过深入的探讨。从抽象层面上讲,契约时交互双方或者多方就某一问题达成的一种共识,使确保正常交互指定的一系列的规范。...也即是说,同样对于我们的计算服务的例子,如果服务端试图通过抛出一个FaultException来提供错误(如下面的代码所示),客户端最后捕获到的仅仅是一个FaultException异常
WCF客户端和服务端的框架体系相互协作,使得开发人员可以按照我们熟悉的方式进行异常的处理:在服务操作执行过程中抛出异常(FaultException),在调用服务时捕获异常,完全感觉不到“分布式”的存在...为了实现这样的效果,WCF在内部为我们作了很多。 消息交换是WCF进行通信的唯一手段,消息不仅仅是正常服务调用请求和回复的载体,服务端抛出的异常,甚至是服务的元数据都是通过消息的形式传向客户端的。...我们可以这样来简单地描述WCF异常处理框架的功能实现:WCF服务端将抛出的FaultException异常进行序列化,并根绝消息的SOAP规范(SOAP 1.1或SOAP 1.2)和WS-Addressing...反序列化的结果即实现对FaultException的重建,WCF最终将重建的FaultException异常抛出,对于最终的开发者而言,感觉就像服务端抛出的FaultException直接被客户端捕获了一样...如果在执行过程中,抛出出FaultException异常,WCF会获取当前DispatchOperation的FaultFormatter,调用Serialze方法对异常对象进行序列化。
一、当异常从服务端抛出 对于一个典型的WCF服务调用,我个人倾向于将潜在抛出的异常费为两种类型:应用异常(Application Exception)和基础结构(Infrastructure Exception...前者为应用级别,主要体现为执行某个服务操作的业务逻辑抛出的异常;而后者则是业务无关的,通过WCF本身的基础架构抛出,主要体现在对象的序列化、消息的处理、消息传输和消息的分发等等。...图2 客户端捕获从服务端抛出的异常 从上面的实例演示中,我们可以获知WCF在默认情况下的异常处理行为:对于服务端抛出的异常(这里主要指应用异常),客户端捕获到的总一个具有相同异常消息的System.ServiceModel.FaultException...对于所有从服务端抛出的异常,只有FaultException和直接或间接继承自FaultException的异常才能被序列化,并最终通过消息返回给服务的调用端。...也就是说,对于应用了开启IncludeExceptionDetailInFaults的ServiceDebug服务行为的WCF服务,在执行服务操作抛出的异常信息,可以通过包含在客户端捕获的FaultException
【转载请注明出处:令仔很忙(【JAVA调错】—-JBoss发布多个项目时抛出webAppRootKey错误)】
第18集 WCF服务应该抛出fault 异常 Throwing fault exceptions from a WCF service 这集的中心意思是WCF服务如果有异常,应该throw出来fault...FaultException用来表示一个基于xml的和平台无关的SOAP,这样就确保了客户端的平台无关性。 ? 下面来试验一下效果: 1. host起这个service ? 2....其实前面抛出的FaultReason 和 FaultCode都是可以获取的。...现在我们已经改成了FaultException,再试验了一下。 ? it works。...如果在实际的coding中,应该是在服务端的代码上加个大的try-catch块,然后在catch块中throw出一个FaultException。 Thank you.
关键的是如何实现让EHAB处理客户端进行服务调用抛出的异常。 我们知道,客户端进行 服务调用抛出的异常类型总是FaultException(包括FaultException)。...采用这样的方式来直接处理调用WCF服务抛出的异常,显然具有很大的局限:如果服务不错任何处理,客户端捕获的永远是FaultException(不包括FaultException)异常,如果采用...当然,在服务端的操作实现中你可以根据具体的场景抛出FaultException异常,并通过不同类型的错误明细(TDetail)封装具体的错误信息,那么客户端就可以针对具体的FaultException...在ProvideFault方法中,先判断抛出的异常是否是FaultException,如果是则不作处理(在这种情况下,一般是服务提供者人为抛出的,并不希望再作进一步的处理)。...所以,将ServiceExceptionDetail作为错误契约时必须的。
一、异常的抛出与Close的失败 一般情况下,当服务端抛出异常,客户客户端的服务代理不能直接关闭,WCF在执行Close方法的过程中会抛出异常。我们可以通过下面的例子来证实这一点。...WCF服务在客户端的调用程序如下所示: 1: using System; 2: using System.ServiceModel; 3: using Artech.ExceptionHandlingDemo.Contracts...在上面一篇文章中,我们就谈到过:WCF通过信道栈实现了消息的编码、传输及基于某些特殊功能对消息的特殊处理,而绑定对象是信道栈的缔造者,不同的绑定类型创建出来的信道栈具有不同的特性。...一般情况下,对于客户端来说,信道在下面两种情况下状态会变成Faulted: 调用超时,抛出TimeoutException 调用失败,抛出CommunicationException 所以正确的客户端进行服务调用的代码应该如下面的代码所示...下面的代码演示了基于ChannelFactory创建服务代理的WCF客户端编程方式,对于直接通过强类型服务代理(继承ClientBase的服务代理类型)进行服务调用具有相同的结构。
YashanDB JDBC 查询时抛出 YAS-02094 current session has been killed or canceled 异常首页 ꁇ YashanDB JDBC 查询时抛出...YAS-02094 current session has been killed or canceled 异常业务在执行 SQL 语句时抛出了 YAS-02094 current session has
2.创建一个WCF客户端对象。 --WCF客户端是表示某个WCF服务的一个本地对象,客户端可以使用这种表示形式与远程服务进行通信。 ...--当客户端应用程序调用第一个操作时,WCF将自动打开基础通道,并在回收对象时关闭基础通道。 ...TimeoutException timeout) { sc.Abort(); } catch(CommunicationException...{ sc.Abort(); } 4.处理错误 --由操作返回的SOAP错误导致引发的任何System.ServiceModel.FaultException...对象 --至少将应用程序设置为能够处理可能的System.TimeoutException和System.ServiceModel.CommunicationException异常 5.配置和保护客户端
第20集 通过实现IErrorHandler接口来统一处理WCF里的异常 Centralized exception handling in WCF by implementing IErrorHandler...当Exception 发生时,先进入ProvideFault方法,然后直接return 出这个FaultException给客户端,避免客户端的等待。同时,异步调用HandleError方法。...创建一个ServiceBehaviour 特性类来告诉WCF服务端当发生异常时,我们要使用上一步创建的GlobalErrorHandler 类。...,如果是的话可以抛出一个我们定义的DivideByZeroFault)。...如果是在WCF的实际项目中应该还是比较好用的吧。 Thank you。
在任何Application的开发中,对不可预知的异常进行troubleshooting时,异常处理显得尤为重要。对于一般的.NET系统来说,我们简单地借助try/catch可以很容易地实现这一功能。...我们发现Client catch住的不是我们Service端真正抛出的DivideByZeroException Exception,而是一个比较General的FaultException。...我们通过includeExceptionDetailInFaults属性设为true,那么如果Service抛出Exception,WCF会简单得包装这个Exception并把它置于Soap中Response...可以看到我们我们Catch的是一个FaultExceptionType的Exception,不是原来的FaultException。...这也正是WCF把这个列入ServiceDebug Service Behavior的原因。
该部分主要涉及WCF提供的异常处理模型和对WCF异常处理底层实现的分析,包括异常的序列化和反序列化、异常的传播、异常的屏蔽等。对于非分布式的单进程应用,异常处理无非就是简单的抛出异常和捕获异常而已。...异常的封送(Exception Marshaling):服务端抛出的异常如何进行序列化以便能够传递到客户端。...敏感信息的屏蔽(Sensitive Information Shielding):抛出的异常常常包含敏感信息,直接将服务操作执行过程抛出的异常直接返回客户端,存在较大安全隐患。...在WCF中,所有的异常信息都是通过FaultException类来传播的,可以通过其泛型参数来传播自定义的信息。...WCF并不直接进行FaultException异常和错误消息之间的交换,其通过一个System.ServiceModel.Channels.MessageFault对象来完成,此外消息的格式化通过FaultFormatter
WCF实现将服务器端的错误信息返回到客户端 2011-12-21 11:37 by Ref Tian, 398 visits, 收藏, 编辑 最近在园子里转看到有人对如题的实现有疑问,今天有时间就写了项目把实现简单的讲解一下...,如果你是牛逼人物那就绕道吧,哥不想浪费你的时间,现在开始: 默认WCF是不允许将服务器的异常信息返回到客户端的(主要是客户端不一定能够识别clr的异常信息),如果你有这方面的需求可以通过SOAP的Fault...如果有異常就返回下面定義的數據契約的結構數據 2.使用系统的异常类型 [FaultContract(typeof(DivideByZeroException))] 在契约实现类中将异常抛出...throw new FaultException(new DivideByZeroException("這個是自定義的異常!"))...FaultException exception:这个抓取的是系统异常类型 注意这里获取异常的信息的方法是exception.Detail.Message,
之前做项目时碰到了这个问题,所以项目上考虑采用长连接,自动管理连接池,当连接超时后,自动重建,保持会话,这样在业务层就不需要再去处理连接超时的问题。...具体的思路是,在程序启动时,先将需要使用长连接的连接放到长连接容器中,并设置连接的最大数量,在使用时,轮询使用连接,当使用时捕获到异常时,自动切换到下一个连接,并重建上一个连接。...expression(_instance); return true; } catch (System.ServiceModel.CommunicationException.../// /// WCF长连接容器 /// /// 待创建的WCF服务类型...,如果创建失败,也会抛出异常 public AliveConnectionContainer(int maxConnection, params string[]
, 或者返回的是ObjectResult且要求的返回协商数据类型是json, 且我们用的是System.Text.Json来序列化(模式是它), 且我们的响应用要求的编码是utf-8 那么在业务方法中抛出的任何...// 或者Client 主动取消请求后 用this.HttpContext.RequestAborted.ThrowIfCancellationRequested() 或者任何地方抛出的...不同的编码响应结果不一样 明明抛出异常了, 但是utf-8还能收到200 ok的response http code 产生这个Bug的代码 SystemTextJsonOutputFormatter 对应的是用