高效的Java异常处理 - 编程入门网

故障屏障的下一个要务是以一种可控的方式来结束操作。这具体的意义要取决于你应用的设计，但通常包括产生一个可通用的回应给可能正在等待的客户端。如果你的应用是一个Web service，这就意味着在回应中用soap:Server的<faultcode>和通用的失败信息<faultstring>来建立一个SOAP故障元素<fault>。如果你的应用于浏览器交流，这个屏障就会安排好一个通用的HTML回应来表明需求是不能被处理的。

在一个Struts的应用里，你的故障屏障会以一种全局异常处理器的形式出现，并被配置成处理RuntimeException的任何子类。你的故障屏障类将延伸org.apache.struts.action.ExceptionHandler类，必要的话，重写它的方法来实施用户自己的特别处理。这样就会处理好不小心产生的故障情况和在处理一个Struts动作时发现的故障。图2显示的就是应变和故障异常。

图2 应变和故障异常

如果你使用的是Spring MVC架构，你可以继承SimpleMappingExceptionResolver类，并配置成处理RuntimeException和它的子类们，这样很容易的就建起了故障屏障。通过重写resolveException的方法，你可以在使用父类的方法来把需求导引到一个发出通用错误提示的view组件之前，加入你需要的用户化的处理。

当你的架构包含了故障屏障，程序员都知晓了后，再写出一次性的故障异常的冲动就会锐减。结果就是应用中出现更干净，更易于维护的代码。

高效的Java异常处理(5)

架构中应变的处理

将故障处理交与屏障后，主要组件间的应变交流变得容易多了。一个应变代表着与主要返回结果同等重要的另外一种方法结果。因此，检查的异常类型是一个能够很好地传递应变情况的存在并提供必要的信息来与它竞争的工具。这个方式借助于Java编译器的帮助来提醒程序员关于他们所用的API的方方面面以及提供全套的方法输出的必要性。

仅仅使用方法的返回值类型来传递简单的应变是可能的。比如，返回一个空引用，而不是一个具体的对象，可以意味着对象由于一个已定义的原因不能被建立。Java I/O的方法通常返回一个整数值－1，而不是字节的值或字节的数来表示文件的结尾。如果你的方法的语义简单到可以允许的地步，另一种返回值的方法是可以使用的，因为它摒弃了异常带来的额外的花销。不足之处是方法的调用方要检测一下返回的值来判断是主要结果，还是应变结果。但是，编译器没有办法来保证方法调用者会使用这个判断。

如果一个方法有一个void的返回类型，异常是唯一的方法来表示应变发生了。如果一个方法返回的是一个对象的引用，那么返回值只可能是空或非空（null and non-null)。如果一个方法返回一个整数型，选择与主要返回值不冲突的，可以表示多种应变情况的数值是可能的。但是这样的话，我们就进入了错误代码检查的世界，而这正式Java异常模式所着力避免的。

提供一些有用的信息

定义不同的故障报告的异常类型是没什么道理的，因为故障屏障对所有异常类型一视同仁。应变异常就有很大的不同，因为它们的原意是要向方法调用者传递各种情况。你的架构可能会指出这些异常应该继承java.lang.Exception或一个指定的基类。

不要忘记你的异常应该是百分百的Java类型，你可以用它来存放为你的特殊目的服务的特殊字段，方法，甚至是构造器。比如，被假想的processCheck()方法抛出的InsufficientFundsException这个异常类型就应

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!