|
锁定老帖子 主题：抛出异常还是约定返回值
精华帖 (0) :: 良好帖 (2) :: 新手帖 (1) :: 隐藏帖 (1)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2012-02-17
这两种方式都有其可取之处， 个人觉得语言还是会走约定这一方向。 说白了，异常只是一个特别的返回值。
|
| 返回顶楼 | |
|
发表时间：2012-02-17
mayday85 写道 我觉得异常的好处是直接返回栈低
只有一层的话，用返回值比较理想吧 用异常感觉整个控制流程比较舒服,代码更直观,而且很多异常可以通用,但性能方面确实是个问题,系统里面涉及多了这种处理方式,估计是一大隐患 |
| 返回顶楼 | |
|
发表时间：2012-02-17
如果LZ项目用的是String的话，可以考虑aop
具体执行情况，可以保持在一个map中，执行到哪步了，每部分返回的状态。这样根据map应该可以判断下面的逻辑了。 |
| 返回顶楼 | |
|
发表时间：2012-02-17
第一种:N个前置条件的检验,放到action里面做,如果不满足返回相关页面之类的
优点:开发直接简单 缺点:思维直接控制层充斥着这样的业务逻辑,很乱,复用性不强,换个action执行这个,还要再组装 支持第一种 这种前端参数判断在action层做判断才是合理的， 如果考虑复用的话 可以在超类做统一验证。 还有一点 是正常流程就不要用异常来控制流程。 |
| 返回顶楼 | |
|
发表时间：2012-02-17
个人觉得提供一个检测的方法，如果满足才调用，调用时发现条件不满足直接返回异常即可
|
| 返回顶楼 | |
|
发表时间：2012-02-17
悲剧了 写道 gtssgtss 写道 action：
简单的方法，不过我并不喜欢 这个耦合也太严重了,快回到解放前了. 就是，有个项目发现就是这样写的。恶心死我了。还说什么这样方便，到处都是传递Map，方法的参数都必须用map取出来 |
| 返回顶楼 | |
|
发表时间：2012-02-17
悲剧了 写道 具体场景如下:
现在要执行一个业务操作方法,这个业务方法执行要有N个前置条件满足才能执行 现在使用统一MVC架构,调用者要收到反馈,知道没ok,根据反馈进行一些列的后续操作,比如通知用户去哪完善,怎么完善 那么怎么处理? 第一种:N个前置条件的检验,放到action里面做,如果不满足返回相关页面之类的 优点:开发直接简单 缺点:思维直接控制层充斥着这样的业务逻辑,很乱,复用性不强,换个action执行这个,还要再组装 第二种:N个前置条件和业务方法在一块组成一个service方法,直接调用就ok了 作为有追求的coder,我们肯定要第二种,那么第二种问题来了 问题: 这一系列走一流程,写成一个方法完成,那么前置条件到底是第一个不满足,还是第N-1个不满足,怎么得到反馈 解决方式1:抛出不同的异常来完成通知 好处:不满足方法的约定,直接给出异常, 缺点:感觉上犯了异常代替了正常流程的问题,不是很确定 解决方式2:根据返回值来通知相关情况,但这种检测条件满足否 有点:性能方面,约定一些列的final String 或者 Eunm ,也算直观吧 缺点:方法返回值承载了太多东西 大家有什么看法?转头什么的扔吧 Action中会有一些Action相关的逻辑， Service中也会有一些Service相关的逻辑。 这两者没有冲突，关键是业务的完整性。 对于业务逻辑执行失败的状态，可以用一个自定义Exception，保存状态码。Service层抛出异常带状态码，Action接住获取状态码就知道是什么错误了。 |
| 返回顶楼 | |
|
发表时间：2012-02-17
封装一个异常包含约定代码，如果发布成服务，统一拦截。把异常转为约定代码返回给客户端
|
| 返回顶楼 | |
|
发表时间：2012-02-17
定义一个检测的公共类，检测方法，返回检测的结果值，
根据不同的值，在公共的错误解释类中，返回该值对应的错误解释 |
| 返回顶楼 | |
|
发表时间：2012-02-17
最后修改：2012-02-17
在service层对可能发生的问题抛出异常 然后在action层捕捉 异常本身就是用来做这种事的 。。
|
| 返回顶楼 | |
