首页 新闻 搜索 专区 学院

请教:业务层出现可预知且无法继续往下处理时如何向上反馈

0
悬赏园豆:20 [已解决问题] 解决于 2017-02-10 15:08

标题抽象了点,举个例子:程序判断到某一个对象为空(或者其它不能继续的情况),到底是该抛出一个异常,还是返回一个状态(码)。

公司新项目,架构要求方法的返回对象是业务数据,如果出现不能继续处理的情况,统统抛出异常。

个人表示对这种方式的处理有点重,不知道各位是怎么处理的,一般哪种情况处理比较好?

 

heartoffreshbird的主页 heartoffreshbird | 初学一级 | 园豆:184
提问于:2017-02-09 16:10
< >
分享
最佳答案
0

当然是异常好了啊。

返回值的状态应该只有成功和不成功,没有成功一半的说。

如果是一个异步操作可能有汇报状态一说。

如果改成状态的话。题主的代码可能是这样

fun main(){
    int hr = func1();  
   
     if(checkhr(hr)){
        hr = func2();
        checkhr(hr);
    }
}
fun checkhr(int hr){
 switch(hr){
     case 1:...
        break;  
     case 2:
      ...
        break;  
    }
}    

所以,总有一天,你会被你的状态玩坏的。

少年,回想起被恐惧支配的日子了么。

收获园豆:10
长蘑菇星人 | 小虾三级 |园豆:1832 | 2017-02-09 16:37

 不是所有方法都返回状态码,只有那些必须告诉调用方处理失败的原因。个人觉得异常处理会不会太啥性能上的损耗之类的

heartoffreshbird | 园豆:184 (初学一级) | 2017-02-10 09:34

@heartoffreshbird: 你想多了。没有经过性能分析不要随便下结论。你所说的损耗就是一个异常堆栈而已。

长蘑菇星人 | 园豆:1832 (小虾三级) | 2017-02-10 09:52

@长蘑菇星人: 你说的错误码的缺点.用异常也一样有的.

吴瑞祥 | 园豆:28820 (高人七级) | 2017-02-10 10:59

@吴瑞祥: 异常有一个好处是可以中断当前程序向下执行,这个是错误码无法实现的。

异常可以方便跟踪调试。而且可以避免业务之间的错误调用(比如遗漏状态码检查)。

长蘑菇星人 | 园豆:1832 (小虾三级) | 2017-02-10 11:04

@吴瑞祥: 异常统一处理,并不会造成代码爆炸。省去了检查状态码,只专注于核心业务。妥妥的提升开发效率。

长蘑菇星人 | 园豆:1832 (小虾三级) | 2017-02-10 11:13

@长蘑菇星人: 那用状态码也是一样的.调用方能不管调用结果吗?

吴瑞祥 | 园豆:28820 (高人七级) | 2017-02-10 11:51

@吴瑞祥: 这个其实就看你怎么考虑了。

如果对系统特别熟悉,熟知所有状态码,并且可以妥善处理,那么完全没有问题。

反正我是觉得,如果业务跑不下来,就应该停下来,而不是假装正常(告诉调用者,你拿着这个纸,去边上看结果,完了再来找我)。

长蘑菇星人 | 园豆:1832 (小虾三级) | 2017-02-10 12:09

@长蘑菇星人: 根据查询的相关资料,貌似用异常方式更便于统一处理。现在暂时接受这种处理方式

heartoffreshbird | 园豆:184 (初学一级) | 2017-02-10 15:06

 不过楼上说的也有道理,这种东西有时候没有标准答案

heartoffreshbird | 园豆:184 (初学一级) | 2017-02-10 15:08
其他回答(1)
0

1.所有的操作接口统一返回值.

2.返回结果包括:是否成功-错误码-错误提示消息

3.业务错误不抛出异常,能逻辑判断的都不要让他抛出异常

4.架构要求抛出异常这种事情.我只能说早点走吧.

收获园豆:10
吴瑞祥 | 园豆:28820 (高人七级) | 2017-02-09 16:30

某个比较核心的业务方法处理如果失败,起码要告诉失败的原因,比如添加购物车、创建订单等,架构是要我们通过异常方式抛出,然后在UI层捕获异常信息。个人觉得通过此处理方法太重(也许是对异常的恐惧,哈哈)

支持(0) 反对(0) heartoffreshbird | 园豆:184 (初学一级) | 2017-02-10 09:30

@heartoffreshbird: 不是性能问题.仔细对比一下就会明白.逻辑判断比异常处理只有优点没有缺点.

我的框架都是统一返回值.所有接口都会返回操作响应码,上层调用时直接通过逻辑判断来处理逻辑错误.

然后用全局异常捕捉.处理异常.

异常是什么意思.就是开发过程中无法预计的错误.如果你用异常处理业务逻辑错误了.

那真正的异常你怎么办?

支持(0) 反对(0) 吴瑞祥 | 园豆:28820 (高人七级) | 2017-02-10 10:03

@吴瑞祥: 倒是能够区分,业务异常可以用一个继承Exception的自定义异常。

支持(0) 反对(0) heartoffreshbird | 园豆:184 (初学一级) | 2017-02-10 10:57

@heartoffreshbird: 你觉得一种业务错误就写一个异常实现容易管理.

还是一种异常定一个错误码枚举容易管理.这个代码量的差别你想想够怕

支持(0) 反对(0) 吴瑞祥 | 园豆:28820 (高人七级) | 2017-02-10 10:58

@吴瑞祥: 现在是用的是同一个业务异常类,只是不用的场景传递的消息不同而已。我只是在想通过throw异常实现是否合理以及与返回状态码这种方式,哪种性能更好点。

支持(0) 反对(0) heartoffreshbird | 园豆:184 (初学一级) | 2017-02-10 11:04

@heartoffreshbird: 返回状态码在各方面都比异常要更优.

可能你们的架构没学过软件工程.我记得是教科书里的写的.能用逻辑判断的地方就不要抛异常.

不然整个架构就会混起来.什么是异常.什么是逻辑错误.分都分不清楚

支持(0) 反对(0) 吴瑞祥 | 园豆:28820 (高人七级) | 2017-02-10 11:05

我现在为了保持代码风格的一致性(随波逐流),采用抛出异常的方式

支持(0) 反对(0) heartoffreshbird | 园豆:184 (初学一级) | 2017-02-10 11:06
清除回答草稿
   您需要登录以后才能回答,未注册用户请先注册