当被调用的服务操作发生异常时,可以直接把异常的原始内容传回给客户端.在WCF中,服务器传回客户端的异常,通常会使用 FaultException,该异常由这么几个东东组成: 1.Action:在服务调用中,action标头比较重要,它是塞在SOAP消息的Headers元素下面的,是消息头的一部分,action用来对服务操作进行定义的.用小学生能听懂的话说,就是某个服务操作的“学号”,通道层在消息调度时,会根据它来寻找要调用的Operation.记得老周举过例子,就好比你去王老板家里,你得知道王老…

前面几篇烂文中所介绍到的错误方式,都是在操作协定的实现代码中抛出 FaultException 或者带泛型参数的detail方案,有些时候,错误的处理方法比较相似,可是要每个操作协定去处理,似乎也太麻烦,此时就应当考虑统一处理了. 在 System.ServiceModel.Dispatcher 命名空间下,有一个 IErrorHandler 接口,这个接口就是让我们统一处理错误的. 先来认识一下这个接口. public interface IErrorHandler { bool Handle…

原谅我这个新手,对大神们来说这么简单的问题,竟折腾了我一个上午,仅此文章做个记录,供以后备用. 自定义错误页面(custom error pages)在asp.net webform里的配置请看http://www.cnblogs.com/luohongwei/p/3638357.html mvc里稍有不同,主要是因为mvc本身是路由分发的,当你请求某个路由时其实这里使用的是httperror 也就是iis的错误页面(个人拙见), 所以这里最重要的是配置httpErrors 这个节点,当然为了同…

工作了几年,写过程序也运营过网站,自定义错误也很熟悉了,最近再做项目发现有同事写了这样的代码 if (action != null) { id = Request.QueryString["id"].GetString().GetInt(); if (!IsPostBack) { DataInit(); if (action.Equals("edit")) { BindData(); } } } else { Response.Redirect("/err…

在上一篇烂文中,老周给大伙伴们介绍了 IErrorHandler 接口的使用,今天,老周补充一个错误处理的知识点——错误协定. 错误协定与IErrorHandler接口不同,大伙伴们应该记得,上回我们是把自己实现IErrorHandler接口的类型添加到ChannelDispatcher中的,也就是说,IErrorHandler处理的是通道层的错误,它可以捕捉到多个服务操作上发生的错误.而错误协定是面向协定层的,它是通过 FaultContractAttribute 来声明的,这个特性在上一篇文…

最近折腾换电脑的事,博客就更新慢了点.好,不废话,直入正题. 前面老周介绍过,SOAP消息中的错误信息是用一个 Fault 元素来包装的,前面老周也讲了其中的 FaultCode 元素,即可以对错误信息进行标识.并且也提到了,Fault 元素下的 faultstring 元素就是 FaultReason 所指定的内容. 今天咱们再了解另一个包装元素——detail.可以把 FaultReason 理解为对错误信息的文本概述,而 detail 元素则可以用于错误的详细信息,该元素下面你可以自由地放…

定义和用法 set_error_handler() 函数设置用户自定义的错误处理函数. 该函数用于创建运行时期间的用户自己的错误处理方法. 该函数会返回旧的错误处理程序,若失败,则返回 null. 语法 set_error_handler(error_function,error_types) 参数 描述 error_function 必需.规定发生错误时运行的函数. error_types 可选.规定在哪个错误报告级别会显示用户定义的错误.默认是 "E_ALL". 提示和注释 提示:…

这里所说的错误处理主要是指服务代码中抛出的异常,即开发人员主动抛出的错误当然,由于网络问题或者配置不正确,会引发连接超时的错误,但这里老周要说的是,我们在实现服务逻辑时主动抛出的异常,尤其是对客户端传入的参数的验证上面. WCF的异常信息一般会通过 FaultException 类来包装.理论和概念性的东西,大家可以去查资料,老周向来不喜欢谈那些,下面咱们通过实例来了解一下 FaultException. 定义服务协定. [ServiceContract(Namespace = "demo-ap…

一.应用场景 对于B/S应用程序,在部署到正式环境运行的过程中,很有可能出现一些在前期测试过程中没有发现的一些异常或者错误,或者说只有在特定条件满足时才会发生的一些异常,对于使用ASP.NET MVC开发的应用程序站点,在部署到IIS上后,如果开发人员未对程序进行错误处理,那么一旦程序出现未处理的错误或异常,用户将看到一个让人感到及其困惑的错误堆栈跟踪页面,使得站点的用户体验下降,从程序的角度上来说,不做自定义错误处理也不利于程序出问题时的根源查找,因为很多时候有些错误只在特定条件下满足时才重现…

问题描述: 在上一篇博文 ".net自定义错误页面实现" 中已经介绍了在.net中如何实现自定义错误页面实现(有需要者可以去上一篇博文了解),单纯按照上一篇博文那样设置,能够实现所有请求的异常自定义跳转,但是这样又会产生一个问题:当通过ajax提交请求获取接口提交请求,如果出现未处理的异常也会被重定向到自定义错误页面. 针对ajax请求或者接口请求,这样返回一个重定向页面,用户体验显然不是太友好,针对这个问题,下面简单总结一下我自己的想法和解决方案,当然不一定科学和合理,所以也希望有大…