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。如果一个方法必须同时处理多个异常，就必须在头内指出所有异常。

就像下例展示的那样，用逗号对他们进行分割：

class Animation

    {

    public Image loadImage（Strint s）  throws EOFException,MalformedURLException

    {

    ……

    }

    }

然而，我们不需要通告内部java错误，也不应该通告自RuntimeException衍生出来的异常。

好的异常处理

好异常处理提供了处理程序错误的统一机制。事实上，Java语言通过向调用者提出异常警告的方式而显着地提升了软件开发中的异常处理能力。这种方式把Java语言中的“方法（method）”进行了扩展和增强，使之包括了自身的错误条件。下面就让我们看一个例子，这个例子说明了这种情况。

以下是FileInputStream构造器之一的原型：

public FileInputStream（String name） throws FileNotFoundException Java

的方法和构造器必须声明他们在被调用时可能“扔出”的异常，采用的关键字就是“throws”。这种在方法原型中出现的异常提示增加了编程的可靠性。

显而易见，这种方式是向方法的调用者提示了可能出现的异常条件，这样调用者就可以对这些异常作出适当的相应处理。以下代码示意我们是如何捕获并且处理FileNotFoundException 这一异常的：

try

    {

    FileInputStream fis = new FileInputStream（args[0]）；

    // other code here …

    }

    catch （FileNotFoundException fnfe）

    {

    System.out.println（"File: " + args[0] + " not found. Aborting."）；

    System.exit（1）；

    }

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 构造器”就是一种异常捕获代码模块，它可以处理所有扔给它的可能异常。

以下是catchall处理器的实例：

try

    {

    // code here with checked exceptions

    }

    catch （Throwable t）

    {

    t.printStackTrace（）；

    }

我得承认，我自己在编写一般程序的时候就曾经用过这种技术；但是，在编写关键程序的时候这种类型的构造器一定要避免使用，除非他们被授权可以和中央错误处理器联合使用才可以这样做。

除此之外，catchall构造器不过只是一种通过避免错误处理而加快编程进度的机制。

异常处理的一个不足之处是难以采用优良的错误处理策略。从低容内存状态恢复、写入错误和算法错误等异常情况都不是轻易能得到解决的。你可以尝试一下循环、垃圾收集和提醒用户等常用技术来应付以上的局面。

恶劣的处理方法

和许多Java特性及其API类似，Java的异常处理机制也有“霸王硬上弓”类的滑稽错误。比方说，为了扔出某个异常竟然毫不犹豫地用“new”关键词为其分配内存就是这样的例子。

我自己不知道有多少次就因为犯了这种错误而在严肃的编译器面前屡屡碰壁。在这种情况下，我们其实都是在伺候语言而不是让语言为我们所用。还有我们碰到的OutOfMemoryErrors就是异常处理的缺陷。这一处理过程是：

使用finally模块关闭文件，解析异常以得到出现问题的方法和代码行。在这一过程之内最大的缺陷是需要捕获OutOfMemoryError，而这一异常却并不是可检查异常！想想看，内存耗尽是相当常见的情况。任何与内存使用状态紧密相关的程序都应当捕获和处理这一错误。

使用异常时的一些建议

1.异常控制的设计宗旨并不是用来代替一些简单的测试。只有在异常情况下才使用异常！

2.不要过分细化异常。不要在每个语句上都加上异常处理，最好将整个任务都放在try块内。如果其中有一项操作失败，可以随即放弃任务。

3.不要“压制”异常。对于需要通告异常的方法，我们可以改用捕捉的方法来将异常强行关闭，如果真的出现异常，那个异常会被“静悄悄”的忽略。如果觉得产生的异常会非常重要，就必须多费些功夫，对其进行正确的控制。

4.不要介意异常的传递。如果调用的方法会产生异常，比如readLine方法，他们天生就能捕捉自己可能产生的异常，在这种情况下，一种更好地做法是将这些异常传递出去，而不是自己动手来捕捉它。