扫描二维码,下载安卓APP
下载安卓APP箭头
客服QQ
箭头给我发消息

客服QQ:2698585038
论坛 >编程语言 >java 设计异常处理API的最佳实践

java 设计异常处理API的最佳实践

634348197137发布于 2017-06-26 10:55查看:9511回复:1

        说了这么多,让我们来说说如何设计一个好的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吧。来看下面的代码:

1498445536195520.jpg

        上面的catch段仅仅抑制了异常,什么也没做。这是因为客户针对SQLException无计可施。何不使用下面的方法呢?

1498445558112711.jpg

        将SQLException转换成RuntimeException。如果SQLException发生时,catch语句抛出一个新的RuntimeException异常。正在执行的线程会挂起,异常爆出来。然而,我并没有破坏逻辑层,因为它不需要进行不必要的异常处理,尤其是它根本不知道怎么处理SQLException。如果catch语句需要知道异常发生的根源,我可以用getCause()方法,这个方法在JDK1.4中所有异常类中都有。

        如果你确信逻辑层可以采取某些恢复措施来应对SQLException时,你可以将它转换成更有意义的checked exception。但我发现仅仅抛出RuntimeException,大部分时间里都管用。

        3. 如果自定义的异常没有提供有用的信息的话,请不要创建它们。

        下面的代码有什么错误?

1498445581957856.jpg

        它没有给出任何有效的信息,除了提供一个异常名字意外。不要忘了Java异常类就像其他的类一样,当你在其中增加方法时,你也可以调用这些方法来获得更多信息。

        我们可以在DuplicateUsernameException中增加有效的方法,例如:

1498445609330329.jpg

        新版本的DuplicateUsernameException提供两个方法:requestedUsername()返回请求的姓名,availableNames()返回与请求姓名相类似的所有姓名的一个数组。客户端可以知道被请求的姓名已经不可用了,以及其他可用的姓名。如果你不想获得其他的信息,仅仅抛出一个标准的异常即可:

1498445628695699.jpg

        如果你认为客户端不会采取任何措施,仅仅只是写日志说明用户名已存在的话,抛出一个unchecked exception:

1498445654576452.jpg

        另外,你甚至可以写一个判断用户名是否已经存在的方法。

        还是要重复一遍,当客户端的API可以根据异常的信息采取有效措施的话,我们可以使用checked exception。但对于所有的编程错误,我更倾向于unchecked exception。它们让你的代码可读性更高。

        4. 将异常文档化

        你可以采用Javadoc’s @throws标签将你的API抛出的checked和unchecked exception都文档化。然而,我更喜欢写单元测试。单元测试可看作可执行的文档。无论你选择哪一种方式,都要让客户端使用你的API时清楚知道你的API抛出哪些异常。下面是针对IndexOutOfBoundsException的单元测试:

1498445688311157.jpg

        当调用blankList.get(10)时,上面的代码会抛出IndexOutOfBoundsException。如果不是如此的话,fail(“Should raise an IndexOutOfBoundsException”)会显式的让测试失败。通过写单元测试,你不仅记录了异常如何运作,也让你的代码变得更健壮。

收藏(0)0
查看评分情况

全部评分

此主贴暂时没有点赞评分

总计:0

回复分享

版主推荐

    共有1条评论

    • Mr ken
    • YUI
    • cappuccino
    • mr jack
    • IT宅男
    • Mright
    • 选择版块:

    • 标题:

    • 内容

    • 验证码:

    • 标题:

    • 内容

    • 选择版块:

    移动帖子x

    移动到: