文章目录
- 为什么要异常处理
- 不用异常处理是怎样的
- 通过异常处理我们能做什么
- 异常堆栈信息一定要记得打印
- 没用的异常处理
- 什么情况下不用抛出异常
- for循环中的try catch
- try catch 行数太多无法定位问题
- service中需要加try catch么
- service什么时候必须加try catch
- 接口返回的情况
- 查询到列表为空算是失败吗
为什么要异常处理
主要是可控性更好。
不用异常处理是怎样的
代码报错立刻中止执行。
通过异常处理我们能做什么
1、保证代码结构性。 例如controller的接口,要考虑到客户的体验,返回代码和msg。
2、打日志记录问题。
3、可以继续抛异常,也可以return,也可以记录完日志之后继续执行代码。
异常堆栈信息一定要记得打印
catch到异常后,一般有2种方法。
1、e.printStackTrace() 或 log.info(“异常了”,e); 直接打印。
2、throw e; 继续抛异常,让其他程序处理。
这2种都是可以的。
但是如果不打印,那么是非常不推荐的,因为排查的时候会找不到信息。
没用的异常处理
代码如下:
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。
异常,拿到提示信息。
查询到列表为空算是失败吗
这个要看情况。
如果只是查询接口,入参条件不同,结果当然能为空。表示根据条件没有搜索到结果,查询是成功的。
如果查询结果是其他业务的前提,那么应该算失败。 例如,接口调用退票业务,没有查到票,那么退票业务没有完成,肯定是失败的。