/**
* 修改用户信息
* @param user 要修改的用户数据
*/
public void updateUser(User user) {
User userOrig = userDao.getUserById(user.getUserID());
if (null == userOrig) {
throw new ServiceException(“用户不存在”);
}
if (userOrig.isLocked()) {
throw new ServiceException(“用户被锁定,不允许修改”);
}
if (!user.getVersion().equals(userOrig.getVersion())) {
throw new ServiceException(“用户已经被别人修改过,请刷新重试”);
}
// TODO 保存用户数据 …
}
这样一来只要我们检查到不允许保存的项目,我们就可以直接throw 一个新的异常,异常机制会帮助我们中断代码执行.
接下来有2种选择:
-
在controller 使用try-catch进行处理.
-
直接把异常抛给上层框架统一处理.
第1种方式是不可取的 ,注意我们抛出的ServiceException,它仅仅逻辑处理异常,并且我们的方法前面没有声明throws ServiceException,这表示他是一个非受查异常.controller也没有关心会发生什么异常.
为什么不定义成受查异常呢? 如果是一个受查异常,那么意味着controller必须要处理你的异常.并且如果有一天你的业务逻辑变了,可能多一种检查项,就需要增加一个异常,反之需要删除一个异常,那么你的方法签名也需要改变,controller也随之要改变,这又变成了紧耦合,这和用状态码123表示处理结果没有什么不同.
我们可以为每一种检查项定义一个异常吗? 可以,但是那样显得太多余了.因为业务逻辑处理失败的时候,根据我们需求,我们只需要通知用户失败的原因(通常应该是一段字符串),以及服务器受理失败的一个状态码(有时可能不需要状态码,这要看你的设计了),这样这需要一个包含原因属性的异常即可满足我们需求.
最后我们决定这个异常继承自RuntimeException.并且包含一个接受一个错误原因的构造器,这样controller层也不需要知道异常,只要全局捕获到ServiceException做统一的处理即可,这无论是在struct1,2时代,还是springMVC中,甚至servlet年代,都是极为容易的!
异常不提供无参构造器 ,因为绝对不允许你抛出一个逻辑处理异常,但是不指明原因,想想看,你是必须要告诉用户为什么受理失败的!
如此一来,我们只需要全局统一处理下 ServiceException 就可以了,很好,spring为我们提供了ControllerAdvice机制,有关ControllerAdvice,可以查阅springMVC使用文档,下面是一个简单的示例:
@ControllerAdvice(basePackages = { “com.xxx.xxx.bussiness.xxx” })
public class ModuleControllerAdvice {
private static final Logger LOGGER = LoggerFactory.getLogger(ModuleControllerAdvice.class);
private static final Logger SERVICE_LOGGER = LoggerFactory.getLogger(ServiceException.class);
/**
* 业务受理失败
*/
@ResponseBody
@ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
@ExceptionHandler(ServiceException.class)
private JSONResult handleServiceException(ServiceException exception) {
String message = “业务受理失败,原因:” + exception.getLocalizedMessage();
SERVICE_LOGGER.info(message);
JSONResult json = new JSONResult();
json.serCode(500001); // 500000表示系统异常,500001表示业务逻辑异常
json.setMessage(message);
return json;
}
}
在这个时候,我们就可以很轻松的处理各种情况了.
注意一点,在这个类中,我们定义了2个log对象,分别指向 ServiceException.class 和 ModuleControllerAdvice.class . 并且处理 ServiceException的时候使用了info级别的日志输出,这是很有用的.
-
首先,ServiceException一定要和其他的代码错误分离,不应该混为一谈.
-
其次,ServiceException并不一定要记录日志,我们应该提供独立的log对象,方便开关.
接下来你可以在修改用户的时候想客户端响应这样的JSON
{
code: 200001,
message: “业务受理失败,原因:用户名称不存在!”
}
如此一来没有任何地方需要关心异常,或者业务逻辑校验失败的情况.用户也可以得到很友好的错误提示.
如何对异常进行分类
如果你只需要一句概括,那么直接定义一个简单的异常,用于中断处理,并且与用户保持友好交互即可.
如果不可能一句话描述清楚,并且包含附加信息,比如需要在日志或者数据库记录消息ID,此时可能专门针对这种重要/复杂业务创建独立异常.
上述两种情况因为web系统,是用户发起请求之后需要等待程序给予响应结果的.
如果是后台作业,或者复杂业务需要追溯性.这种通常用流程判断语句控制,要用异常处理.我们认为这些流程判断一定在一个原子性处理中.并且检查到(不是遇到)的问题(不是异常)需要记录到用户可友好查看的日志.这种情况属于处理反馈,并不叫异常.
综上,笔者通常分为如下几类:
-
逻辑异常,这类异常用于描述业务无法按照预期的情况处理下去,属于用户制造的意外.
-
代码错误,这类异常用于描述开发的代码错误,例如NPE,ILLARG,都属于程序员制造的BUG.
-
专有异常,多用于特定业务场景,用于描述指定作业出现意外情况无法预先处理.
各类异常必须要有单独的日志记录,或者分级,分类可管理.有的时候仅仅想给三方运维看到逻辑异常.
写在后面的注意
异常设计的初衷是解决程序运行中的各种意外情况,且异常的处理效率比条件判断方式要低很多.
上面这句话出自<java编程思想>,但是我们思考如下几点:
业务逻辑检查,也是意外情况
UnknownHostException,表示找不到这样的主机,这个异常和NoUserException有什么区别么?换言之,没有这样的主机是异常,没有这样的用户不是异常了么? 所以一定要弄明白什么是用异常来控制逻辑,什么是定义程序异常.另外,欢迎关注公众号Java笔记虾,后台回复“后端面试”,送你一份面试题宝典!
异常处理效率很低
书中所示的例子,是在循环中大量使用try-catch进行检查,但是业务系统,用户发起请求的次数与该场景天壤地别.淘宝的双十一是个很好的反例.但是请你的系统上到这个级别再考虑这种问题.
-
系统有千万并发,不可能还去考虑这些中规中矩的按部就班的方式,别忘了MVC本来就浪费很多资源,代码量增加很多.
-
业务系统也存在很多巨量任务处理的情况.但是那些任务都是原子性的,现在MVC中的controller和service可不是原子性的,不然为什么要区分这么多层呢.
-
如果那么在乎效率,考虑下重写Throwable的fillStackTrace方法.你要知道异常的开销大到底大在什么地方,fillStackTrace是一个native方法,会填充异常类内部的运行轨迹.
不要用异常进行业务逻辑处理
我们先来看一个例子:
//这是一个非常典型的反例,也是一个误区.
/**
* 处理业务消息
* @param message 要处理的消息
*/
public void processMessage(Message message) {
try{
// 处理消息验证
// 处理消息解析
// 处理消息入库
}catch(ValidateException e ){
// 验证失败
}catch(ParseException e ){
// 解析失败
}catch(PersistException e ){
// 入库失败
}
}
上述代码就是典型的使用异常来处理业务逻辑.这种方式需要严重的禁止!上述代码最大的问题在于,我们如何利用异常来自动处理事务呢?
然而这和我们的异常中断service没有什么冲突.也并不是一回事.
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数Java工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则几千的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年Java开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Java开发知识点,真正体系化!
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!
如果你觉得这些内容对你有帮助,可以扫码获取!!(备注Java获取)
总结
至此,文章终于到了尾声。总结一下,我们谈论了简历制作过程中需要注意的以下三个部分,并分别给出了一些建议:
- 技术能力:先写岗位所需能力,再写加分能力,不要写无关能力;
- 项目经历:只写明星项目,描述遵循 STAR 法则;
- 简历印象:简历遵循三大原则:清晰,简短,必要,要有的放矢,不要海投;
以及最后为大家准备的福利时间:简历模板+Java面试题+热门技术系列教程视频
《一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》,点击传送门即可获取!
能力;
2. 项目经历:只写明星项目,描述遵循 STAR 法则;
3. 简历印象:简历遵循三大原则:清晰,简短,必要,要有的放矢,不要海投;
以及最后为大家准备的福利时间:简历模板+Java面试题+热门技术系列教程视频
[外链图片转存中…(img-L1HLsYjq-1711883793939)]
[外链图片转存中…(img-Fh0eYnty-1711883793939)]
[外链图片转存中…(img-oNcxYKNf-1711883793940)]
《一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》,点击传送门即可获取!