Java编程中异常处理的优劣

　　Java编程中的异常处理是一个很常见的话题了，几乎任何一门介绍性的Java课程都会提到异常处理。不过，我认为很多人其实没有真正掌握正确处理异常情况的方法和策略，较多也就不过了解个大概，知道概念。我想对三种不同程度和质量的Java异常处理进行了讨论，所阐述的处理异常的方式按手法的高下分为：

　　好，不好和恶劣三种。

　　同时提供了一些解决这些问题的技巧。

　　首先解释一些java异常处理中必须搞清楚的定义和机制。Java语言规范将自Error类或RuntimeException类衍生出来的任何违例都称作“不可检查”（Unchecked）异常；其他所有异常则称作“可检查”（Checked）异常。

　　所谓可检查异常，是指我们应该自行处理的异常。至于处理的手段，要么加以控制（try catch），要么通告（throws）他们有可能产生。通常，应捕捉那些已知如何处理的异常，而通告那些不知如何处理的异常。

　　而对那些不可检查异常来说，他们要么在我们的控制之外（Error），要么是我们首先就不该允许的情况（RuntimeException）。

　　至于异常的指定，Java的规则非常简单：一个方法必须通告自己可能产生的所有可检查异常。编写自己的方法时，并不一定要通告出方法实际可能产生的每一个异常对象，要想理解什么时候必须要方法的throws丛句来通告异常，就必须知道对一个异常来说，他只有可能在下面四种情况下才会产生：

　　1.调用了可能产生异常的方法。比如BufferedReader类的readLine方法。该方法通告java.io.IOException异常

　　2。发现到一个错误，并用throw语句产生异常。

　　3.出现一个编程错误。比如a[-1] = 0。

　　4.Java产生内部错误。

　　如果出现头两种情况之一，必须告诉打算使用自己方法的人：假如使用这个方法，可能造成一个异常的产生（即在方法头上使用throws），一个简单的记忆方法：

　　只要含有throw,就要通告throws。如果一个方法必须同时处理多个异常，就必须在头内指出所有异常。

　　Java异常处理还有其他一些的特性，这就是可检查异常、用户定义异常和在JDK 1.4中推出的 新型Java记录API（Java Logging API）。java.lang.Exception的所有子类都属于可检查异常。可检查异常（checked exception）是扔出该异常的方法所必须提示的异常，这种异常必须被捕获或者向调用者提示。用户定义异常（User-defined exceptions）是定制的异常类，这种异常类扩展了java.lang.Exception类。优良的Java程序规定定制异常封装、报告和处理他们自己独有的情况。较新的Java记录API（logging API）则可以集中记录异常。 不好的Java异常处理

　　不好的一面包括两种情况：滥用不可检查异常（unchecked exceptions）和滥用catchall构造器等。这两种方式都使得问题变得复杂起来。

　　有一种类别的异常属于RuntimeException的子类，这种异常不会受到编译器的检查。比如，NullPointerException和 ArrayStoreException就是这种类型异常的实例。程序员可以对RuntimeException进行子类化以回避检查异常的限制，从而便于产生这些异常的方法为其调用者所使用。

　　专业的开发团队应当只允许在很少的情况下才可以这样做。

　　第二种异常处理的陋习是catchall构造器。所谓的“catchall 构造器”就是一种异常捕获代码模块，它 可以处理所有扔给它的可能异常。