个人推荐使用异常机制,就算使用返回值包括错误,还是少不了要捕捉异常,不如只捕捉异常好了,只是多一个异常类型而已。再说,从历史的角度看,异常机制的出现就是为了优化用返回值报错的机制的。
同意楼上观点,自定义一个业务异常类,可以加上错误码字段,方便准确的记录和跟踪异常。
为什么要定义一个异常返回哦,你可以返回一个model,里面至少包括两个节点:
1、status(状态枚举码)
2、errorMessage
3、其他节点
这样在使用这个接口的时候,很容易判断和知道是什么错误,并根据不同的错误编码做响应的逻辑处理
赞同!
这样的话,控制器里面会非常复杂,如果一个控制器方法里面使用多个业务层方法,都得接受哦一个封装的model类型,判断status。
@友个人: 如果你这样说,是不是要考虑程序分层问题了呢?
我平时的使用,你看看能否有帮助:
1、控制器就是一个调通桥梁(UV和业务处理中间桥梁)
在控制器里面,不会做任何业务逻辑处理,值需要把业务层的逻辑处理结果返回给调用放即可
2、具体的业务逻辑处理都是当道业务层去处理
3、这样做的目的,就是业务解耦
建议全局异常,不论你是在代码的任何地方都可使用;如果使用返回值,调用栈过深,还需要一层一层返回
有道理
如果这样处理,是不是太暴露了。
其实道理很简单,正常的业务逻辑,是会根据返回的不同错误做不同的业务处理,如果按照你的方式,那就麻烦了哦,调用放无论什么错误,都是收到的一个全局异常处理加工后数据
.........
你可以这样子的架构你的程序。你在一个配置文件中写上全居的异常处理码 比如
301=用户登录失败,密码不正确
302=用户登录失败,用户名不正确
然后在代码中的业务方法中,自定义异常类,这个你可以定义多个异常类,但是须得有一个父类比如你类中 BusiException
然后你在控制层返回给客户端的时候 加 try(){}catch(BusiException) 然后你从异常中获取到你的异常码 比如301,然后从配置文件中读取对应的内容。这样子就可以完美的响应给客户端了