一．异常介绍

任何的异常都是Throwable类，并且在它之下包含两个字类Error / Exception，而Error仅在当在Java虚拟机中发生动态连接失败或其它的定位失败的时候，Java虚拟机抛出一个Error对象。典型的简易程序不捕捉或抛出Errors对象，你可能永远不会碰到需要实例化Error的应用，那就让我们关心一下Exception。

Unchecked Exception.：包括 Error与RuntimeException. 这类异常都是RuntimeException的子类。

Checked Exception:除了Error与RuntimeException，其他剩下的异常. 这类异常都是Exception的子类 。在编译时在语法上必须处理的异常，因此必须在语法上以try..catch加以处理；

二．设计异常的最佳实践 （Best Practises for Designing the API）

 1． 当要决定是采用checked exception还是Unchecked exception的时候，你要问自己一个问题，“如果这种异常一旦抛出，客户端会做怎样的补救？”

[原文：When deciding on checked exceptions vs. unchecked exceptions, ask yourself, "What action can the client code take when the exception occurs?"]

如果客户端可以通过其他的方法恢复异常，那么这种异常就是checked exception；如果客户端对出现的这种异常无能为力，那么这种异常就是Unchecked exception；从使用上讲，当异常出现的时候要做一些试图恢复它的动作而不要仅仅的打印它的信息，总来的来说，看下表：

Client's reaction when exception happens	Exception type
Client code cannot do anything	Make it an unchecked exception
Client code will take some useful recovery action based on information in exception	Make it a checked exception

此外，尽量使用unchecked exception来处理编程错误：因为unchecked exception不用使客户端代码显示的处理它们，它们自己会在出现的地方挂起程序并打印出异常信息。Java API中提供了丰富的unchecked excetpion，譬如：NullPointerException , IllegalArgumentException 和 IllegalStateException等，因此我一般使用这些标准的异常类而不愿亲自创建新的异常类，这样使我的代码易于理解并避免的过多的消耗内存。

 2． 保护封装性（Preserve encapsulation）

不要让你要抛出的checked exception升级到较高的层次。例如，不要让SQLException延伸到业务层。业务层并不需要（不关心？）SQLException。你有两种方法来解决这种问题：

l         转变SQLException为另外一个checked exception，如果客户端并不需要恢复这种异常的话；

l         转变SQLException为一个unchecked exception，如果客户端对这种异常无能为力的话；

多数情况下，客户端代码都是对SQLException无能为力的，因此你要毫不犹豫的把它转变为一个unchecked exception，看看下边的代码：

public void dataAccessCode(){     try{         ..some code that throws SQLException     }catch(SQLException ex){         ex.printStacktrace();     } }

上边的catch块紧紧打印异常信息而没有任何的直接操作，这是情有可原的，因为对于SQLException你还奢望客户端做些什么呢？（但是显然这种就象什么事情都没发生一样的做法是不可取的）那么有没有另外一种更加可行的方法呢？

public void dataAccessCode(){     try{         ..some code that throws SQLException     }catch(SQLException ex){         throw new RuntimeException(ex);     } }

 上边的做法是把SQLException转换为RuntimeException，一旦SQLException被抛出，那么程序将抛出RuntimeException,此时程序被挂起并返回客户端异常信息。

 如果你有足够的信心恢复它当SQLException被抛出的时候，那么你也可以把它转换为一个有意义的checked exception, 但是我发现在大多时候抛出RuntimeException已经足够用了。

 3． 不要创建没有意义的异常（Try not to create new custom exceptions if they do not have useful information for client code.）

看看下面的代码有什么问题？

public class DuplicateUsernameException     extends Exception {}

它除了有一个“意义明确”的名字以外没有任何有用的信息了。不要忘记Exception跟其他的Java类一样，客户端可以调用其中的方法来得到更多的信息。

我们可以为其添加一些必要的方法，如下：

public class DuplicateUsernameException     extends Exception {     public DuplicateUsernameException         (String username){....}     public String requestedUsername(){...}     public String[] availableNames(){...} }

在新的代码中有两个有用的方法：reqeuestedUsername(),客户但可以通过它得到请求的名称；availableNames(),客户端可以通过它得到一组有用的usernames。这样客户端在得到其返回的信息来明确自己的操作失败的原因。但是如果你不想添加更多的信息，那么你可以抛出一个标准的Exception:

throw new Exception("Username already taken");

更甚的情况，如果你认为客户端并不想用过多的操作而仅仅想看到异常信息，你可以抛出一个unchecked exception:

throw new RuntimeException("Username already taken");

另外，你可以提供一个方法来验证该username是否被占用。

 很有必要再重申一下，checked exception应该让客户端从中得到丰富的信息。要想让你的代码更加易读，请倾向于用unchecked excetpion来处理程序中的错误（Prefer unchecked exceptions for all programmatic errors）。

4． Document exceptions.

你可以通过Javadoc’s @throws 标签来说明（document）你的API中要抛出checked exception或者unchecked exception。然而，我更倾向于使用来单元测试来说明（document）异常。不管你采用哪中方式，你要让客户端代码知道你的API中所要抛出的异常。这里有一个用单元测试来测试IndexOutOfBoundsException的例子：

public void testIndexOutOfBoundsException() {     ArrayList blankList = new ArrayList();     try {         blankList.get(10);         fail("Should raise an IndexOutOfBoundsException");     } catch (IndexOutOfBoundsException success) {} }

上边的代码在请求blankList.get(10)的时候会抛出IndexOutOfBoundsException,如果没有被抛出，将fail("Should raise an IndexOutOfBoundsException")显示说明该测试失败。通过书写测试异常的单元测试，你不但可以看到异常是怎样的工作的，而且你可以让你的代码变得越来越健壮。

 三．使用异常的最佳实践（Best Practices for Using Exceptions）

1． 总是要做一些清理工作（Always clean up after yourself）

如果你使用一些资源例如数据库连接或者网络连接，请记住要做一些清理工作（如关闭数据库连接或者网络连接），如果你的API抛出Unchecked exception，那么你要用try-finally来做必要的清理工作：

public void dataAccessCode(){     Connection conn = null;     try{         conn = getConnection();         ..some code that throws SQLException     }catch(SQLException ex){         ex.printStacktrace();     } finally{         DBUtil.closeConnection(conn);     } } class DBUtil{     public static void closeConnection         (Connection conn){         try{             conn.close();         } catch(SQLException ex){             logger.error("Cannot close connection");             throw new RuntimeException(ex);         }     } }

DBUtil是一个工具类来关闭Connection.有必要的说的使用的finally的重要性是不管程序是否碰到异常，它都会被执行。在上边的例子中，finally中关闭连接，如果在关闭连接的时候出现错误就抛出RuntimeException.

 2． 不要使用异常来控制流程（Never use exceptions for flow control）

下边代码中，MaximumCountReachedException被用于控制流程：

public void useExceptionsForFlowControl() {    try {         while (true) {             increaseCount();         }     } catch (MaximumCountReachedException ex) {     }     //Continue execution }   public void increaseCount()     throws MaximumCountReachedException {     if (count >= 5000)         throw new MaximumCountReachedException(); }

上边的useExceptionsForFlowControl()用一个无限循环来增加count直到抛出异常，这种做法并没有说让代码不易读，但是它是程序执行效率降低。

记住，只在要会抛出异常的地方进行异常处理。

3． 不要忽略异常

当有异常被抛出的时候，如果你不想恢复它，那么你要毫不犹豫的将其转换为unchecked exception，而不是用一个空的catch块或者什么也不做来忽略它，以至于从表面来看象是什么也没有发生一样。

4． 不要捕获顶层的Exception

unchecked exception都是RuntimeException的子类，RuntimeException又继承Exception,因此，如果单纯的捕获Exception,那么你同样也捕获了RuntimeException,如下代码：

try{ .. }catch(Exception ex){ }

一旦你写出了上边的代码（注意catch块是空的），它将忽略所有的异常，包括unchecked exception.

5． Log exceptions just once

    Logging the same exception stack trace more than once can confuse the programmer examining the stack trace about the original source of exception. So just log it once.

总结

这里给出了一些关于异常处理的一些最佳实践，我并不想开始另一轮的关于checked exception 和 unchecked exception的争论。你可以根据自己的实际情况定制自己异常处理，我坚信我们将有更好的办法来处理我们代码中的异常。