|
锁定老帖子 主题：抛出异常还是约定返回值
精华帖 (0) :: 良好帖 (2) :: 新手帖 (1) :: 隐藏帖 (1)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2012-02-17
jdk中类似的情况都是一个try然后跟着n个catch，这样的好处是日志里面直接就能看到信息，没见过到处return各种枚举或string的
|
| 返回顶楼 | |
|
发表时间：2012-02-18
郑富成 写道 定义一个检测的公共类，检测方法，返回检测的结果值，
根据不同的值，在公共的错误解释类中，返回该值对应的错误解释 呵呵，不错。 |
| 返回顶楼 | |
|
发表时间：2012-02-18
异常。异常代替正常流程这句话害了多少人
|
| 返回顶楼 | |
|
发表时间：2012-02-18
xwf2010_good 写道 第一种:N个前置条件的检验,放到action里面做,如果不满足返回相关页面之类的
优点:开发直接简单 缺点:思维直接控制层充斥着这样的业务逻辑,很乱,复用性不强,换个action执行这个,还要再组装 支持第一种 这种前端参数判断在action层做判断才是合理的， 如果考虑复用的话 可以在超类做统一验证。 还有一点 是正常流程就不要用异常来控制流程。 问题是这个不是前段参数的严重,是后台业务需要前置条件满足,比如用户要满足一定级别 还要有一定的积分才能操作 |
| 返回顶楼 | |
|
发表时间：2012-02-18
郑富成 写道 定义一个检测的公共类，检测方法，返回检测的结果值，
根据不同的值，在公共的错误解释类中，返回该值对应的错误解释 等于是再抽取一层,把严重单独拿出来,谢谢,这个的确更清晰了 |
| 返回顶楼 | |
|
发表时间：2012-02-18
melin 写道 封装一个异常包含约定代码，如果发布成服务，统一拦截。把异常转为约定代码返回给客户端
非常担心性能问题,如果不符合的情况出现比较多得时候 |
| 返回顶楼 | |
|
发表时间：2012-02-18
直接将需要反馈给用户的异常在service里用异常抛出-，-
|
| 返回顶楼 | |
|
发表时间：2012-02-18
如果是一些参数检测，如参数为空或null，这样的还是在action中检测，用框架的话更方便，如果是业务层的前置条件，这样的还是放在业务层，这个不属于actioin的范围了，这是业务逻辑了，用异常就好。现在cpu的性能可以忽略异常的开销了，不要总是拿性能否定。合理的代码结构，更利于维护和重构。
|
| 返回顶楼 | |
|
发表时间：2012-02-18
xiebo1983 写道 在service层对可能发生的问题抛出异常 然后在action层捕捉 异常本身就是用来做这种事的 。。
+1我也一直这么用,好像有一老贴,是这论坛老大讨论的 |
| 返回顶楼 | |
|
发表时间：2012-02-18
http://www.iteye.com/topic/2038
|
| 返回顶楼 | |
