java编程中异常处理的优劣观

　关键字: 异常,通告(throws),throw,try,catch,RuntimeException,不可检查(Unchecked)异常, 可检查(Checked)异常

　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)，一个简单的记忆方法： 

1 3 5 7

class Animation {　　public Image loadImage(Strint s) throws EOFException,MalformedURLException 　　{　　　…………　　}}

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

好异常处理

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

public FileInputStream(String name) throws FileNotFoundException Java

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

1 3 5 7 9 11

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构造器等。这两种方式都使得问题变得复杂起来。 
专业的开发团队应当只允许在很少的情况下才可以这样做。

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

1 3 5 7 9

try { // code here with checked exceptions } catch (Throwable t) { t.printStackTrace(); }

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

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

恶劣

　和许多Java特性及其API类似，Java的异常处理机制也有"霸王硬上弓"类的滑稽错误。比方说，为了扔出某个异常竟然毫不犹豫地用"new"关键词为其分配内存就是这样的例子。 
使用finally模块关闭文件，解析异常以得到出现问题的方法和代码行。在这一过程之内最大的缺陷是需要捕获OutOfMemoryError，而这一异常却并不是可检查异常！想想看，内存耗尽是相当常见的情况。任何与内存使用状态紧密相关的程序都应当捕获和处理这一错误。

使用异常时的一些建议

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

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

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