Java高质量代码之 — 异常

前言:由于上一个星期工作繁忙,利用上下班和晚上睡前空余的时间拜读了秦小波老师的《改善Java程序的151建议》,感觉廓然开朗,注意到了很多平时在编写代码中并不会注意的问题,甚至感觉自己对Java只是略懂皮毛,不足以登大雅之堂,特此与读者分享读书笔记,以下内容摘自《改善Java程序的151建议》一书和笔者的理解


Java高质量代码系列文章
      面向对象篇:http://ray-yui.iteye.com/blog/1926984
      数据类型篇:http://ray-yui.iteye.com/blog/1927251
          字符串篇:http://ray-yui.iteye.com/blog/1927647
      数组与集合(1):http://ray-yui.iteye.com/blog/1928170
      数组与集合(2):http://ray-yui.iteye.com/blog/1930155
      枚举与注解:http://ray-yui.iteye.com/blog/1931408
      泛型与发射:http://ray-yui.iteye.com/blog/1933127
                  异常:http://ray-yui.iteye.com/blog/1938946
                      杂:http://ray-yui.iteye.com/blog/1942591


程序是不完美的,开发者是没有办法穷举所有软件运行中可能遇到的问题,异常的情况随时都会出现,而我们就需要异常来帮助我们描述我们程序当中发生的意外问题.


1.提倡异常封装
      Java语言的异常处理机制可以确保程序的健壮性,提供系统的可用率,但异常的API通常是比较"低级" 什么是低级别?那就是不包含业务的,只是程序员才能看懂的异常信息,而对于用户来说,基本就是看天书,什么是NullPointException?这些都是纯计算机语言的描述,而对于用户而言是需要业务级别的异常信息,所以我们提倡对异常的封装,异常封装有3个优势

      1.提高系统的友好性,由于系统提供的异常都是低级的,例如打开一个文件,如果文件不存在,则会报出FileNotFoundException,此时若然我们不对异常进行封装直接将栈信息输出到用户端,那用户根本就不知道是什么意思,我们应该对异常进行业务性的说明,例如提示文件不存在等.

      2.提高系统的可维护性,我们很多时候喜欢将多个异常信息直接使用一个异常的父类Exception或RuntimeException来表达,这种做法是不推荐的,就算将异常栈信息输出,维护人员还是要追寻到代码的层面才可以定位到异常发生的地方,这对系统的维护性造成了很大的影响,我们应该分开编写异常信息.

      3.解决Java异常机制自身的缺憾,Java当中的只要代码触发异常,就会跳到这个异常对应的catch块当中处理,而忽略其他catch块,这对于单独的一个代码块是没有问题的,但若然是多个代码块或一个链式的处理,链当中可能多一个节触发了异常,但我们最终是会看到一个异常,所以使用异常封装就能实现记录多个异常信息,请观察以下代码

public class MyException extends RuntimeException {

	private static final long serialVersionUID = 701064983280219053L;
	private List<Throwable> exceptionList = new ArrayList<Throwable>();

	public MyException(List<? extends Throwable> cause) {
		this.exceptionList.addAll(cause);
	}

	// 调用时
	public static void main(String[] args) {
		List<Throwable> exceptionList = new ArrayList<Throwable>();

		// 第一代码片段
		try {

		} catch (Exception e) {
			exceptionList.add(e);
		}

		// 第二代码片段
		try {

		} catch (Exception e) {
			exceptionList.add(e);
		}

		// 第三代码片段
		try {

		} catch (Exception e) {
			exceptionList.add(e);
		}

		// 正式抛出异常
		if (exceptionList.size() > 0) {
			throw new MyException(exceptionList);
		}
	}
}

2.采用异常链传递异常
      我们的JavaEE项目一般是三层结构,持久层,逻辑层,展现层,持久层是负责读取数据的,例如我们现在需要加载一个文件作为数据,但此时报出FileNotFoundException,由于该异常是检查性异常,所以必须在持久层处理或往上抛,但此时若然使用上抛的方式,逻辑层在调用时基本无法知道持久层为什么会出现这个错误,这个错误应该是持久层最清楚的,所以我们应该把异常封装好后传递到逻辑层,请观察以下代码

public void test() {
		File file = new File("/test.xml");
		try {
			FileInputStream fis = new FileInputStream(file);
		} catch (FileNotFoundException e) {
			e.printStackTrace();
			throw new MyException("文件不存在", e);
		}
	}

在持久层封装好自定义的异常类信息后抛出到逻辑层中,逻辑层到展现层亦同理


3.检查性异常尽量转化为非检查性异常
      把所有检查性异常(Checked Exception)都转换为非检查性异常(UncheckedException)是不现实的,因为检查性异常是正常逻辑的一种补充处理手段,在某些条件下必须抛出检查性异常以便上层为底层的错误进行处理,那为什么非要把受检异常转换为非受检异常呢?

      1.检查性异常使接口声明脆弱我们应该面向接口编程,但由于检查性异常大多需要抛出,这就使得在声明接口的时候,需要把抛出的异常类型也一并声明,若然在开发迭代的过程中发现实现类需要抛出更多的异常,那我们就必须要修改接口,这就是类影响接口的情景,其实我们可以看出,在很多著名的框架当中,都在使用着非检查性异常,例如Hibernate,Spring等,特别是Hibernate框架,把底层的JDBC检查性异SQLException全部隐藏了起来而只使用了Hibernate定义的非检查性异常.

      2.检查性异常使代码可读性降低当我们逻辑层调用持久层时,若然抛出了检查性异常,我们的逻辑层必须要对其进行try catch处理,或者再往展现层抛出,这样对持久层的调用者来说意味着,每次调用持久层的方法都需要增加4行代码才能成功调用,这样大大降低了代码的可读性

      3.受检异常增加了开发工作量我们从上面所述可以知道,我们推荐对异常进行封装,上层模块才能更好的处理和显示给用户,但这也导致了底层没完没了的封装,无疑是加重了开发的工作量,但在软件当中,几乎是不存在完美的解决方案,就例如数据库设计中的容量换效率和效率换容量一样,我们只能取其平衡的地方,适当的对异常进行封装

检查性异常有如此多的缺点,所以我们在开发当中通常会将检查性异常转换为非检查性异常,检查性异常的父类为Exception,非检查性的异常父类为RuntimeException,只要我们封装的异常类型是继承RuntimeException就可以抛出非检查性异常,检查性异常提出的是“法律下的自由”,而非检查性异常则是“约定的自由”



4.在使用日志框架时需要注意异常吞噬
      使用开源日志框架,例如log4j等已经在项目当中广泛的使用,请留意以下代码

public class Test {
	Logger logger = LoggerFactory.getLogger(this.getClass());

	public void test() {
		try {

		} catch (Exception e) {
			e.printStackTrace();
			logger.warn("错误信息", e);
			new MyException("错误信息", e);
		}
	}
}

      以上代码是使用日志框架对检查性异常时的公认写法,有项目维护或开发经验的人知道,在项目维护阶段出现错误时,通常客户会将日志文件发送给维护人员,然后维护人员根据日志文件中的错误定位程序进行修复,而不是将在控制台的信息直接复制给维护人员,读者要分清控制台输出和日志文件的概念,printStackTrace方法是将错误的栈信息输出到控制台中,若然此时我们没有使用logger对异常信息进行记录,那我们将会把此异常信息吞噬掉,导致定位错误时将一头雾水,当然项目可能会设置将控制台的信息一并记录到日志文件中,但在开发阶段,我们应该尽量避免这种不稳定的事情发生.


5.不要在finally中处理返回值
      在finllay中处理返回值，是考试和面试题中经常出现的题目,但请谨记,在项目当中绝对不要在finally中处理返回值,请留意以下代码

public static int doSomething(int num) throws Exception {
	try {
		if (num < 0) {
			throw new Exception("error");
		}else{
			return num;
		}
	} catch (Exception e) {
		throw e;
	} finally {
		return -1;
	}
}

public static void main(String[] args) {
	try {
		doSomething(-1);
		doSomething(100);
	} catch (Exception e) {
		System.out.println("永远不会到达");
	}
}

      我们都知道无论是否触发异常运行catch块,finally都会被执行,以上的答案两个结果都返回为-1,而且调用该方法不会抛出异常,而且覆盖了try中的返回值,而且告诉了JVM,我这个方法调用正常返回,没有问题,屏蔽了异常,在Eclipse等IDE中若在finally增加返回值还会提示警告信息,所以切记finally中不要出现返回值,finally应该作释放资源用


6.不要在构造函数中抛出异常
      我们知道类的创建会执行构造函数,其实从语法层面来说完全可以在构造函数中抛出异常,但从系统设计角度来说,尽量不要在构造函数中抛出异常,这样的行为不仅使子类扩展父类的构造函数受到限制,而且也违背了里氏替换原则,除非该类不应该被创建或不想被反射技术创建,则应该在构造函数增加异常


7.使用Throwable获取栈信息
      如何做到对同一个方法(同参数)的调用返回两个不同的结果?请观察以下代码

public static boolean doSomething(){
	StackTraceElement[] stes = new Throwable().getStackTrace();
	
	for(StackTraceElement ste : stes){
		if(ste.getMethodName().equals("test")){
			return true;
		}
	}
	throw new RuntimeException("除test方法外，我不允许其他人调用");
}

public static void test(){
	doSomething();
}

public static void test1(){
	//我报错了
	doSomething();
}

      这里对同一个方法调用,产生了两种结果,为什么呢?因为在创建一个Throwable类时,JVM会记录下栈信息,然后生成Throwable对象,这样我们就可以知道类之间调用的顺序,方法名称和当前行号等等,就可以完成只要调用者不是test方法,就产生错误


8.异常只为异常服务
      异常原本的用意是正常逻辑的一个补充,有时甚至会被当做业务主体来使用,就例如在finally和catch中增加业务代码,但这种做法是不推荐的,导致代码产生了坏味道,所以并不推荐在异常中做过多的业务逻辑处理,除非必须,否者应该尽量避免


9.多使用异常作为信息
      由于我们的应用大多是三层架构,若然不使用异常进行信息的封装传递,我们就必须定义记录信息的变量在三层中互相传递,这样的做法降低了对代码的可读性,而且忽视了Java本身提供的信息传递途径,而在持久层通过异常的封装传递到展现层,最终显示给用户,通过异常类这个载体,可以很好的完成这项工作,例如Struts2都提供了标签让我们更好的输出异常中的信息,更提供了'值栈'给我们,使用<s:debug />看一下,你会看到Exception在里面


总结:
      笔者在本文章中只从《改善Java程序的151建议》中提取部分进行归纳性叙述,推荐各位读者购买这本书,该书不仅从事例中学习,而且涉及到原理,底层的实现,不仅告诉你应该怎么做,还告诉你为什么要这样做.

评论

5 楼 windshome 2013-09-10  

这个话题非常好，有空也看看博主推荐的这本书。

个人认为：Java异常处理这个话题，在开发过程中，最大的问题在于缺乏设计层面的规划，如果有了规划和整体的设计，后边编码就都会顺畅很多。

编码和技巧当然也很重要，但不能从根本上改善情况，解决问题。

我关于异常方面的文章： http://windshome.iteye.com/blog/1860742

4 楼 ray_yui 2013-09-09  

cugbzc 写道

4：在使用日志框架时需要注意异常吞噬。不知道你到底要说什么。
还有最后new MyException("错误信息", e);  就new了一个对象，什么都不做？

new MyException是将检查异常转换为非检查异常抛给上层,这里只是一个事例,不存在业务,请问想怎么做?异常吞噬是指只输出异常到控制台没有记录到日志当中,请问兄台维护项目时看日志文件还是控制台?

3 楼 cugbzc 2013-09-09  

4：在使用日志框架时需要注意异常吞噬。不知道你到底要说什么。
还有最后new MyException("错误信息", e);  就new了一个对象，什么都不做？

2 楼 ray_yui 2013-09-09  

matychen 写道

第4个，logger.warn()。不建议这么写
可以这样，注意逗号，以及不要e.getMessage().
logger.error("some accompanying message", e);
参见:http://slf4j.org/faq.html#exception_message

非常感谢指出错误,已修改

1 楼 matychen 2013-09-09  

第4个，logger.warn()。不建议这么写
可以这样，注意逗号，以及不要e.getMessage().
logger.error("some accompanying message", e);
参见:http://slf4j.org/faq.html#exception_message