小课堂Week10 例外处理设计的逆袭Part3
小课堂Week10
例外处理设计的逆袭Part3
今天是《例外处理设计的逆袭》这本书阅读的第三天，也是最后一天，我们会主要通过实例，对Part2中提出的例外处理等级进行解读。
Level1
Level1的要求是立即中止运行 ，所有例外都往外抛，全部报告给使用者，或者开发者使用。
案例1
我们看一个实例，如下代码存在一些什么样的问题：
public int withdraw(int amount) {
if (amount > 100)
return -1;
else
return 100 - amount;
}
- 问题：使用返回码来表示异常，造成了返回信息的二义性，会导致上游调用复杂，同时也不能清晰表达具体错误原因。
- 解决：用异常来代替返回码。
进一步讨论下，异常名称应该如何命名：
1.ATMException
2.WithdrawException
3.NotEnoughMoneyException
以上三个中，哪一个更好？
从Java异常的定义看，一个异常是能包含一个message和一个其他异常的。
message用来表示错误的原因，cause用来传递上级的异常。
所以我们排除选项3，这个应该在message中表示。
public Throwable(String message, Throwable cause) {
fillInStackTrace();
detailMessage = message;
this.cause = cause;
}
对于选项1和选项2，都表示了异常的来源，都是可以的，这个要看我们具体模块划分的粒度，如果是一个银行系统，那么ATM这个粒度是合适的，而如果是ATM机的系统，withdraw这个粒度是合适的。
最后还要说明一点的就是，自定义异常，建议定义为unchecked exception，这样就对上游代码没有侵入，可以比较顺利的达到传递到最外层的Level1目标。
修改后如下：
public int withdraw(int amount) {
if (amount > 100)
throw new ATMException("余额不足");
else
return 100 - amount;
}
案例2
看下下面这段代码有没有什么问题：
public void close(AutoCloseable res) throws Exception {
try {
res.close();
} catch (Exception e) {
logger.error("关闭资源错误", e);
throw new Exception("关闭资源信息", e);
}
}
- 问题：在catch段中，同时记录了日志和抛出异常
- 解决：根据实际场景，二选一。
何时抛出异常呢，一般是在非外层的模块中，如案例1所示情况。
何时记日志呢，有两种场景：
- 第一是在finnally的场景中，不建议抛出，因为此类清理操作的异常会覆盖掉正常的异常情况。而案例中的代码，也是一个清理操作，是和finnally中代码等价的。所以只要记录日志即可。
public void close(AutoCloseable res) throws Exception {
try {
res.close();
} catch (Exception e) {
logger.error("关闭资源错误", e);
}
}
- 第二是在程序的最外层，这个时候要统一记录日志，但需要注意的是，Exception并不能覆盖Java中的所有的异常，从全面性角度看，我们应该捕获Throwable来记录日志。
public static void main(String[] args) {
try {
//do something
} catch (Throwable e) {
logger.error("关闭资源错误", e);
}
}
Level2
和Level1相同，Level2中异常都往外报，但在错误发生时，故障程序是可以继续运行的。这里主要讨论下在Level2会用到的一些模式：
考虑如下代码逻辑，如何可以在某步执行异常时，确保程序继续运行？
public void runBatchJob(List<Integer> numList) {
int temp = 100;
for (Integer num : numList) {
temp = temp / num;
}
}
我们可以引入一个checkpoint对象，包含establish、recover、drop三个方法。
class NumCheckpoint{
private Integer checkpointedNum;
public void establish(Integer backupNum) {
//备份数据
this.checkpointedNum = backupNum;
}
public Integer recover() {
// 将备份数据还原
return this.checkpointedNum;
}
public void drop() {
// 删除备份资料
}
}
然后在代码的try..catch...finnally块中分别使用，实现异常的恢复
public void runBatchJob(List<Integer> numList) {
//Checkpoint对象
NumCheckpoint numCheckpoint = new NumCheckpoint();
Integer temp = 100;
for (Integer num : numList) {
try {
//establish()
numCheckpoint.establish(temp);
temp = temp / num;
} catch (Exception e) {
//recover()
temp = numCheckpoint.recover();
} finally {
//drop()
numCheckpoint.drop();
}
}
}
此外，我们可以引入一个ErrorCollector来收集异常
public interface ErrorCollector {
List<Exception> getErrors();
void addError(Exception error);
void clear();
int size();
}
public void runBatchJob(List<Integer> numList, ErrorCollector errorCollector) {
//Checkpoint对象
NumCheckpoint numCheckpoint = new NumCheckpoint();
Integer temp = 100;
for (Integer num : numList) {
try {
//establish()
numCheckpoint.establish(temp);
temp = temp / num;
} catch (Exception e) {
//recover()
temp = numCheckpoint.recover();
errorCollector.addError(e);
} finally {
//drop()
numCheckpoint.drop();
}
}
}
}
Level3
Level3是要求在Level2的基础上，提供应急处理方法，确保业务能正确执行。
我们来看一下案例：
public String readUser(String name) {
try {
return readFromDatabase(name);
} catch (Exception e) {
try {
return readFromRedis(name);
} catch (Exception ex) {
throw new RuntimeException(ex);
}
}
}
这段代码实现了Level3的向前恢复的要求，当从数据库获取失败时，从redis来取数，从功能上看是可以的。
但从代码结构看不太好。因为其将一部分的处理放在了catch段中，出现了异常嵌套的情况，这个是异常处理代码的一个禁忌。
所以我们做一下改进，使用循环来替代异常嵌套，逻辑看起来更清晰，而且只需要通过调整循环中的变量，就能实现retry的策略。
public String readUser(String name) {
int attempt = 1;
while (true) {
try {
if (attempt <= 1) {
return readFromDatabase(name);
}
if (attempt == 2) {
return readFromRedis(name);
}
} catch (Exception ex) {
attempt++;
if (attempt > 3) {
throw new RuntimeException(ex);
}
}
}
}
小结
关于《例外处理设计的逆袭》这本书的介绍就到这里结束了，主要是讲了一些我认为比较重要的点，书中还有其他很多精彩的部分也欢迎大家去阅读。最后的最后，这本书的实战性是很强的，所以请大家在工作中多动手、多实践，只有这样才能把知识变成自己的技能。
