异常处理的使用

为什么要异常处理

主要是可控性更好。

不用异常处理是怎样的

代码报错立刻中止执行。

通过异常处理我们能做什么

1、保证代码结构性。 例如controller的接口，要考虑到客户的体验，返回代码和msg。
2、打日志记录问题。
3、可以继续抛异常，也可以return，也可以记录完日志之后继续执行代码。

异常堆栈信息一定要记得打印

catch到异常后，一般有2种方法。
1、e.printStackTrace() 或 log.error(“程序出现异常，error：”,e); 直接打印。
2、throw e; 继续抛异常，让其他程序处理。
这2种都是可以的。
但是如果不打印，那么是非常不推荐的，因为排查的时候会找不到信息。

注：打印异常日志时，如果是log.error不用占位符。

log.error("程序出现异常，error：",e); # 正确 
log.error("程序出现异常，error：{}",e); # 错误，加了占位符反而打印不出来 

没用的异常处理

代码如下：

try {
    userMapper.insert(entity);
    return 1;
} catch (DuplicateKeyException e) {
    throw e;
}

看出什么问题了么，其实这个try catch没有任何作用。
分析下代码的执行过程：
1、发生了DuplicateKeyException，抛出异常。
2、发生其他的异常，还是会抛出异常。
这和不加没有任何区别。

什么情况下不用抛出异常

1、最典型的就是controller面向用户的，肯定不能直接抛出异常，catch到异常之后，直接return相应的提示信息即可。
2、如果是没有相互依赖的批量处理。 那么也可以不抛异常，只记录日志，并返回成功条数即可。 例如，批量插入数据，每条都是独立的，如果有一条错的，其他的照样应该插入。
3、外围有对接result体的，例如调用方是根据isSuccess()来判断是否成功，那么被调用方出现异常，设置success为false和errorMsg即可。

for循环中的try catch

如果for里面有一定的逻辑，建议try catch加在单条上。
这样的好处：
1、出了问题容易定位。
2、单条异常，不影响其他。

try catch 行数太多无法定位问题

一个大try catch固然可以catch到，但是如果出了问题，也不好定位。

service中需要加try catch么

如果每个小方法都加try catch，和返回JsonResult ，实在是麻烦的很。
这里除非逻辑非常简单，否则推荐加try catch的。
但是如果觉得麻烦，返回值不一定要用JsonResult，例如可以是boolean，list等。 这样代码也会简单点。

service什么时候必须加try catch

通常来说，不加也没事，因为外面有controller是一定会有异常拦截器的。
所以无论如何，异常都能被捕获到。

但是有一种特护情况，那就是定时任务。 这样外面没有controller调用，service本身就一定要添加try catch。否则出现了异常，也没有捕获机制和日志记录，是非常危险的。

接口返回的情况

正常，拿到数据来进行操作，或加工下反馈信息。
无论有没有数据都应该是success。

异常，拿到提示信息。

查询到列表为空算是失败吗

这个要看情况。
如果只是查询接口，入参条件不同，结果当然能为空。表示根据条件没有搜索到结果，查询是成功的。

如果查询结果是其他业务的前提，那么应该算失败。 例如，接口调用退票业务，没有查到票，那么退票业务没有完成，肯定是失败的。

finally的使用

finally的应用比较少，单独弄一篇文章不太值当，干脆放到这里了。
finally的作用就是不管怎么，始终执行，一般和try搭配，或者跟在catch后。

注：finally并非一定要跟再catch后，直接try finally也是可以的。
例如外层已经有了try catch，里层的for循环就没必要再加catch了，代码太臃肿，而且对性能有一点点影响。