专题课程
说了这么多，让我们来说说如何设计一个好的API，能够正确抛出异常的。
1. 当要确定是使用checked exception还是unchecked exception时，首先问问自己，当异常发生时客户端如何应对？
如果客户端可以从异常中采取行动进行恢复的，就使用checked exception，如果客户什么也做不了，就用unchecked exception。我指的是，不仅仅是记录异常，还要采取措施来恢复。
还有，我更喜欢unchecked exception，因为不需要强迫客户端API必须处理它们。它们会进一步扩散，直到你想catch它们，或者它们会继续扩散爆出。Java API有许多unchecked exception如NullPointerException, IllegalArgumentException和IllegalStateException。我更愿意用这些Java定义好的异常类，而非我们自己创建的异常类。它们使我们的代码易读，也避免代码消耗更多内存。
2. 保持封装性
不要将针对某特定实现的checked exception用到更高的层次中去。例如，不要让SQLException扩散到逻辑层去。因为逻辑层是不需要知道SQLException。你有两种选择：
– 如果你的客户端有应对措施的话，将SQLException转化成另一个checked exception。
– 如果你的客户端什么也做不了的话，将SQLException转化成一个unchecked exception。
但大部分情况是，客户端对SQLException无能为力。那请将SQLException转换成unchecked exception吧。来看下面的代码：
上面的catch段仅仅抑制了异常，什么也没做。这是因为客户针对SQLException无计可施。何不使用下面的方法呢？
将SQLException转换成RuntimeException。如果SQLException发生时，catch语句抛出一个新的RuntimeException异常。正在执行的线程会挂起，异常爆出来。然而，我并没有破坏逻辑层，因为它不需要进行不必要的异常处理，尤其是它根本不知道怎么处理SQLException。如果catch语句需要知道异常发生的根源，我可以用getCause()方法，这个方法在JDK1.4中所有异常类中都有。
如果你确信逻辑层可以采取某些恢复措施来应对SQLException时，你可以将它转换成更有意义的checked exception。但我发现仅仅抛出RuntimeException，大部分时间里都管用。
3. 如果自定义的异常没有提供有用的信息的话，请不要创建它们。
下面的代码有什么错误？
它没有给出任何有效的信息，除了提供一个异常名字意外。不要忘了Java异常类就像其他的类一样，当你在其中增加方法时，你也可以调用这些方法来获得更多信息。
我们可以在DuplicateUsernameException中增加有效的方法，例如：
新版本的DuplicateUsernameException提供两个方法：requestedUsername()返回请求的姓名，availableNames()返回与请求姓名相类似的所有姓名的一个数组。客户端可以知道被请求的姓名已经不可用了，以及其他可用的姓名。如果你不想获得其他的信息，仅仅抛出一个标准的异常即可：
如果你认为客户端不会采取任何措施，仅仅只是写日志说明用户名已存在的话，抛出一个unchecked exception：
另外，你甚至可以写一个判断用户名是否已经存在的方法。
还是要重复一遍，当客户端的API可以根据异常的信息采取有效措施的话，我们可以使用checked exception。但对于所有的编程错误，我更倾向于unchecked exception。它们让你的代码可读性更高。
4. 将异常文档化
你可以采用Javadoc’s @throws标签将你的API抛出的checked和unchecked exception都文档化。然而，我更喜欢写单元测试。单元测试可看作可执行的文档。无论你选择哪一种方式，都要让客户端使用你的API时清楚知道你的API抛出哪些异常。下面是针对IndexOutOfBoundsException的单元测试：
当调用blankList.get(10)时，上面的代码会抛出IndexOutOfBoundsException。如果不是如此的话，fail(“Should raise an IndexOutOfBoundsException”)会显式的让测试失败。通过写单元测试，你不仅记录了异常如何运作，也让你的代码变得更健壮。
收藏(0)
赞 
粤公网安备44010602001432号