请教：业务层出现可预知且无法继续往下处理时如何向上反馈
0
悬赏园豆：20
[已解决问题]
解决于 2017-02-10 15:08
标题抽象了点，举个例子：程序判断到某一个对象为空（或者其它不能继续的情况），到底是该抛出一个异常，还是返回一个状态（码）。
公司新项目，架构要求方法的返回对象是业务数据，如果出现不能继续处理的情况，统统抛出异常。
个人表示对这种方式的处理有点重，不知道各位是怎么处理的，一般哪种情况处理比较好？
最佳答案
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
不是所有方法都返回状态码，只有那些必须告诉调用方处理失败的原因。个人觉得异常处理会不会太啥性能上的损耗之类的
@heartoffreshbird: 你想多了。没有经过性能分析不要随便下结论。你所说的损耗就是一个异常堆栈而已。
@长蘑菇星人: 你说的错误码的缺点.用异常也一样有的.
@吴瑞祥: 异常有一个好处是可以中断当前程序向下执行，这个是错误码无法实现的。
异常可以方便跟踪调试。而且可以避免业务之间的错误调用（比如遗漏状态码检查）。
@吴瑞祥: 异常统一处理，并不会造成代码爆炸。省去了检查状态码，只专注于核心业务。妥妥的提升开发效率。
@长蘑菇星人: 那用状态码也是一样的.调用方能不管调用结果吗?
@吴瑞祥: 这个其实就看你怎么考虑了。
如果对系统特别熟悉，熟知所有状态码，并且可以妥善处理，那么完全没有问题。
反正我是觉得，如果业务跑不下来，就应该停下来，而不是假装正常（告诉调用者，你拿着这个纸，去边上看结果，完了再来找我）。
@长蘑菇星人: 根据查询的相关资料，貌似用异常方式更便于统一处理。现在暂时接受这种处理方式
不过楼上说的也有道理，这种东西有时候没有标准答案
其他回答(1)
0
1.所有的操作接口统一返回值.
2.返回结果包括:是否成功-错误码-错误提示消息
3.业务错误不抛出异常,能逻辑判断的都不要让他抛出异常
4.架构要求抛出异常这种事情.我只能说早点走吧.
收获园豆：10
某个比较核心的业务方法处理如果失败，起码要告诉失败的原因，比如添加购物车、创建订单等，架构是要我们通过异常方式抛出，然后在UI层捕获异常信息。个人觉得通过此处理方法太重（也许是对异常的恐惧，哈哈）
@heartoffreshbird: 不是性能问题.仔细对比一下就会明白.逻辑判断比异常处理只有优点没有缺点.
我的框架都是统一返回值.所有接口都会返回操作响应码,上层调用时直接通过逻辑判断来处理逻辑错误.
然后用全局异常捕捉.处理异常.
异常是什么意思.就是开发过程中无法预计的错误.如果你用异常处理业务逻辑错误了.
那真正的异常你怎么办?
@吴瑞祥: 倒是能够区分，业务异常可以用一个继承Exception的自定义异常。
@heartoffreshbird: 你觉得一种业务错误就写一个异常实现容易管理.
还是一种异常定一个错误码枚举容易管理.这个代码量的差别你想想够怕
@吴瑞祥: 现在是用的是同一个业务异常类，只是不用的场景传递的消息不同而已。我只是在想通过throw异常实现是否合理以及与返回状态码这种方式，哪种性能更好点。
@heartoffreshbird: 返回状态码在各方面都比异常要更优.
可能你们的架构没学过软件工程.我记得是教科书里的写的.能用逻辑判断的地方就不要抛异常.
不然整个架构就会混起来.什么是异常.什么是逻辑错误.分都分不清楚
我现在为了保持代码风格的一致性（随波逐流），采用抛出异常的方式
