关于catch语句块中要不要写业务逻辑代码

一、前言

在catch中捕获到的异常一定要做处理，不能直接return。

处理方式：

（1）继续抛出

（2）打出日志

反例：

上例中，对捕获到的异常没有做任何处理，这是不合适的，虽然不影响代码的逻辑，但是代码确实出问题了，而又没有将错误内容显示出来，这样会影响代码排除错误。

正例：

上例中，将捕获到的异常信息打印到日志中，这样就可以在不影响业务逻辑的情况下，还知道出现了什么异常，可以进一步解决问题。

二、实例解释

 最近工作中，发现其他人员开发的模块功能中，在catch语句块中调用了业务方法，目的是当try语句块中的业务逻辑执行过程中发生异常，再执行catch语句块中代码。

      上述情况的业务场景是这样的，try语句块中查询redis缓存（try中查询redis的代码有调用了其他开发人员写的逻辑比较复杂的方法，且多个方法调用），catch语句块中查询后端数据库，开发者意图很明显，就是如果查询redis缓存出现异常，则查询后端数据库，看似很完美的代码设计逻辑。但是完美下面也存在一定几率的风险。

       风险分析。暂定该开发人员叫A，如果try语句块中逻辑比较复杂，且调用了其他开发人员（名字为B）的方法，这时候开发人员B在自己的方法中也利用catch捕获了异常，而不是向上抛出异常，这时候问题出现了，A写的代码中catch语句块的业务逻辑有可能不会执行，这就违背了A的设计意图，也就产生了非常讨厌的逻辑bug。开发人员都知道逻辑bug的原因很难找的。

   所以，在日常开发工作，catch语句块中尽量不要写业务逻辑，就打印写异常日志就可以了。

参考：

https://blog.youkuaiyun.com/dhklsl/article/details/85095592

https://blog.youkuaiyun.com/qq_27988539/article/details/84753494?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.channel_param&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.channel_param