第二部分使用checked异常的最佳实践
现在假设有些错误我们确定为checked异常，那么我们针对这些checked异常要怎样编码才合理呢？
1 不要用checked异常做流程控制。无论如何，checked异常也是一种错误。只是我们可以处理（修复）它而已。这种错误和普通业务流程还是有区别的，而且从效率上来说，用异常控制业务流程是不划算的。其实这个问题有时候很难界定，因为checked异常“可以修复”，那么就是说修复后程序照常运行，这样一来真的容易跟普通业务流程混淆不清。比如注册用户时用户名已经存在的问题。这个时候我们要考虑，为什么要用checked异常？这和使用业务流程相比，给我带来了什么好处？（注意checked异常可以修复，这是和unchecked异常本质的区别）照我的理解，checked异常应该是介于正常业务流程和unchecked异常（严重错误）之间的一种比较严重的错误。出现了这种错误，程序无法完成正常的功能是肯定的了，但我们可以通过其他方式弥补（甚至修复），总之不会让程序挂起就是。其实这一点也是设计checked异常时要考虑的问题，也是代价之一吧。
2 对checked异常的封装。这里面包括2个问题：
第一，如果要创建新的checked异常，尽量包含多一点信息，如果只是一条message，那么用Exception好了。当然，用Exception会失去异常的型别信息，让客户端无法判断具体型别，从而无法针对特定异常进行处理。
第二，不要让你要抛出的checked exception升级到较高的层次。例如，不要让SQLException延伸到业务层。这样可以避免方法签名后有太多的throws。在业务层将持久层的所有异常统统归为业务层自定义的一种异常。
3客户端调用含有throws的方法要注意：
第一，不要忽略异常。既然是checked异常，catch clause里理应做些有用的事情??修复它！catch里为空白或者仅仅打印出错信息都是不妥的！为空白就是假装不知道甚至瞒天过海，但是，出来混迟早要还的，迟早会报unchecked异常并程序挂起！非典就是个例子。打印出错信息也好不到哪里去，和空白相比除了多几行信息没啥区别。如果checked异常都被这么用，那真的不如当初都改成unchecked好了，大家都省事！
第二，不要捕获顶层的Exception。你这么干，就是在犯罪！因为unchecked异常也是一种Exception！你把所有异常都捕获了??不是我不相信你的能力，你根本就不知道该如何处理！这样做的直接的后果就是，你的程序一般来说是不会挂起了，但是出现错误的时候功能废了，表面上却看不出什么！当然，深究起来，这也不是什么罪大恶极，如果你在catch里打印了信息，这和上面那条的情况是差不多的。而这2条的共同点就是，没有正确使用checked异常！费了那么大劲设计的checked异常就是给你们上级（客户端）用的，结果你们不会用！真的不如用unchecked干脆利落了！
上一页 [1] [2]
