关于bll业务返回状态码还是要抛出一个异常

[niuqian___123456]

最近非常困惑一个事情：
在bll中通常要进行数据验证，比如注册功能要验证 账号不能重复和手机号不能重复。如果这两个都没有重复才能将数据insert到db中。通常一个系统中还会有其他多处这样的业务需求。那么，遇到这种需求的时候是返回特定的编号来表示，还是通过抛出异常来表示。
比如：账号重复时候返回 -1 手机号重复返回 -2 ，正常通过，注册后返回 id值给消费者。
还是throw CustomException("账号重复") 这样来告诉消费者呢。
我同时在晚上翻阅了资料和技术群进行询问：有些人推荐使用异常的方式来告诉消费者，但是，我有在微软的官方文档和其他文档中查阅到：正常的业务流程不应使用异常来处理 。
这时我就迷惑了，难道是我的理解有误。
欢迎拍砖，欢迎各抒己见

附两个相关文档链接：
http://www.cnblogs.com/aehyok/p/3750122.html
https://msdn.microsoft.com/zh-cn/library/ms173163.aspx

[我有时不是我]

我的处理方式类似于返回特定编号

[niuqian___123456]

引用 1 楼 u010052814 的回复:

我的处理方式类似于返回特定编号

目前也是采用这中方式，不过这几天感觉这种方式很粗陋

[卧槽这是我的昵称吗]

{ "code": 1001, "msg" : "数据库操作异常"}

[娃都会打酱油了]

这些返回的编号其实是你的业务逻辑部分，这根本不是异常，那为什么要返回异常呢？

[以专业开发人员为伍]

引用 楼主 niuqian___123456 的回复:

但是，我有在微软的官方文档和其他文档中查阅到：正常的业务流程不应使用异常来处理 。 这时我就迷惑了，难道是我的理解有误。

如果你只知道抠字眼、走极端，那么就有了理解有误。正常的流程就是指“在讲的、有逻辑设计文档的”，而没有逻辑设计文档的东西就应该走抛出异常流程，让用户回退。假设一个程序员不按照逻辑设计文档的流程去做 if 判断，而是等着系统抛出异常之后再来“隐藏异常”、让用户感觉好像是继续操作下去了，那么这就是滥用异常。 例如，如果业务流程写的是“if 用户名有重复 then 显示1 else if 用户名含有非法字符 then 显示2 else 注册”，这就叫做“正常的业务流程”。这时候你写 bll 时，你要实现3个服务，其中前两个服务都给前端返回 true/false，第三个服务没有返回（或者说只有一个默认的返回）。这就叫做“正常的业务流程”，因为人家设计文档要求你实现3个服务了，你若硬要偷懒给省为1个服务就不正常了。 再举一个例子。假设用户要从页面上将自己的收入分摊到n个账户中，如果逻辑设计文档中告诉你说“先判断如果 n==0 提示用户必须选择至少一个目标账户”，这个时候如果你忽略了这个逻辑设计，那么就是“用异常来取代正常的业务流程”。 但是抠字眼、走极端会产生想反的结果。例如业务逻辑设计文档上本来就没有“if 账户数==0"的判断，或者本来就没有“如果目标文件不存在怎么办”的描述，你非要说“我就是不抛出异常，我就是耗时间等着公司重新设计业务逻辑”，这就走了相反的极端。你这个时候就应该抛出异常，而不是用什么“正常的业务逻辑不应该用异常来处理”的借口。 可见“是非”都是人定的，不是天定的。 比如说，当你的 bll 抛出异常之后，前端隐藏了这个异常，而继续走其它业务逻辑，那么这就是“用异常来取代正常的业务流程”了。而不是你的 bll 来纠结什么是非问题。 你的 bll 根本不知道什么叫做“正常的业务流程”，只有你站在前端的角度才能看明白。有些初学者满脑子都是底层、后端那点代码，硬要辨别是非。实际上这个是非是要从前端应用需求来看待的，不是从底层来决定的。

[以专业开发人员为伍]

这里边体现的是业务处理逻辑设计问题，而你的bll纠结于“是不是要抛出异常”的问题，其实这就是偷换概念了。 假设业务逻辑文档上规定了“在提交申请时，如果用户还没有上传资格证书图片，则应该引导用户去上传图片”。 1. 正常的程序是，先调用 BLL 的一个服务来判断用户是否已经提交了资格证书，然后再调用BLL 的另一个服务 2. 用异常来取代正常处理流程的程序是，先调用BLL 层对“认证申请”操作，抛出异常之后，根据异常信息string来隐藏这个异常，去引导用户去上传图片。 正常的业务流程设计是说“根本走不到BLL层的最后一步”，先进行证书判断。而错误的流程是先去挑战BLL的“提交申请”最终功能，然后当BLL给出一个返回值之后再来重走前一步正常的上传证书流程。 这跟你的“是返回特定的编号来表示，还是通过抛出异常来表示”疑问有什么关系呢？根本不纠结于这里返回什么值。实际上你返回一个值、还是使用系统更规范的异常机制，都是异常。你说来说去都是在说 BLL 对于异常的反馈形式，你把系统规范的异常，你吧你自己定义的不规范地“返回一个错误码”不叫做异常，这其实根本解决不了什么问题。

[以专业开发人员为伍]

你把系统规范的异常叫做“异常”，你吧你自己定义的不规范地返回一个错误码不叫做“异常”，这其实根本解决不了什么问题。 而人家微软文档上说的“不要用异常来处理正常的业务流程”不是站在你的层面上的。人家是从前端业务流程上来说的。也就是我上面举的两种实现的例子： 1. 先调用 BLL 的一个服务判断是否提交了资格证书，然后再调用系统另一个 BLL 来处理注册认证，这就是正常的流程。 2. 先调用 BLL的注册认证服务，然后当BLL（不管是返回一个string、number，还是规范的异常信息）给出错误码之后，又来返回头来进入提交资料图片流程，这就是用异常来取代正常流程了！

[江南小鱼]

你参考微软的错误机制，一般是一个错误编号 微信也有错误码列表，errCode和errMsg相结合

[bidisty]

和应用层交互，可以返回一个说明文档，不应该把Exception直接返给应用层，Exception应在内部处理 如： { "code": ok, "msg" : "资料已完整"} { "code": no, "msg" : "没提交了证书"} 应用层以返回的信息对应处理。 如果你 throw 回Exception，应用层处理非常麻烦。

[niuqian___123456]

引用 8 楼 sp1234 的回复:

你把系统规范的异常叫做“异常”，你吧你自己定义的不规范地返回一个错误码不叫做“异常”，这其实根本解决不了什么问题。 而人家微软文档上说的“不要用异常来处理正常的业务流程”不是站在你的层面上的。人家是从前端业务流程上来说的。也就是我上面举的两种实现的例子： 1. 先调用 BLL 的一个服务判断是否提交了资格证书，然后再调用系统另一个 BLL 来处理注册认证，这就是正常的流程。 2. 先调用 BLL的注册认证服务，然后当BLL（不管是返回一个string、number，还是规范的异常信息）给出错误码之后，又来返回头来进入提交资料图片流程，这就是用异常来取代正常流程了！

感谢sp大神打这么多字，很抱歉这么久才想起来有这个帖子。 您在本条所说的我已经理解。但目前我仍然困惑一点问题： 正常情况下我们会按 1 来处理“提交图片”的这个流程 .那么：在BLL层里 可以实现 a判断用户是否具提交了证书 b未提交的时候将返回一个值tag给 应用层，应用层得到这个值后引导用户进行其他业务。 c已经提交情况可以继续 注册认证 业务 那么问题来了： 判断+注册认证 写到一个bll方法中是否合理？ 假如合理的话： 那个tag为 Exception 合理还是 一个其他的 int，string 或一个引用类型更为合理？

[niuqian___123456]

引用 10 楼 bidisty 的回复:

和应用层交互，可以返回一个说明文档，不应该把Exception直接返给应用层，Exception应在内部处理 如： { "code": ok, "msg" : "资料已完整"} { "code": no, "msg" : "没提交了证书"} 应用层以返回的信息对应处理。 如果你 throw 回Exception，应用层处理非常麻烦。

感谢~