关于用异常控制程序流程的看法

      数据库很强大，它为我们考虑了大多数情况。像数据一致性、多表联接查询、排序等等；似乎我们不需要再去考虑更多，把这些问题统统交给数据库去做就好了。这么做的好处显而易见，而且似乎既然数据库已经提供了如此众多的特性，我们没有不用的道理。当然缺点就是数据库压力增加了，软件的大多数压力都集中到了数据库。
      看起来这似乎不是什么缺点，而且商用数据库还能获得大厂商的技术支持，好处多多。而且压力大了还可以通过增加集群节点来缓解。领域软件都是这么做的，为了安全性。oa、erp、crm等软件一般也把数据一致性问题交给数据库处理，因为方便，一个公司内部使用的软件，并发量一般不会太大，不需要为吞吐量和响应时间考虑太多。甚至我知道有些架构设计连业务逻辑都交给存储过程去做了。不过有些时候巴不得把所有事情都交给数据库去做不见得是个好方法。
      最后，既然你在当前这一层就能处理的情况为什么还要抛异常出去再到上一层处理。就像领导安排你一任务，你遇到的各种情况都跟领导汇报一下但你明明就有能力处理可就是不处理，这样好吗？实际上领导只关心你的处理结果。同样的，你负责的代码能处理的问题就处理，把处理结果告知调用者就行了，这样不是能减少调用者的麻烦吗？在软件工程分工细致的团队，这么做非常有利，代码的责任和人的责任都很明确。
      最后的最后非常感谢snowm同学的回复。分割线上面的就是我要说的。非常感谢您能仔细耐心的把我的帖看完，回复也很仔细。我就不多解释了，下面说下分割线下面的内容。
      本来我举这个例子是为了说明下分割线上面提到的问题。后来仔细想想，这个例子有些粗糙了。本来是想开帖讨论异常和业务状态码、错误码的优劣和应该在哪些情况下使用它们。让我没想到的是，现在居然变成了如何维护数据一致性、数据表设计方面的讨论了。是我说的不清楚还是我的帖太有指向性？
      最近一直在加班，等闲下来了再开新帖吧。我得好好组织下文字。
      再回答snowm的最后一句。得到了啥和失去了啥都在前面说过了，得到了低数据库负载和更细致的分工还有维护业务逻辑的高代价当然还有高水平的程序员。失去了数据库提供的便利。当然我说这些和之前发的帖并不是说一定要怎样，一定不能怎样。这类问题没有绝对对错。只有适不适用、方不方便、简单困难和哪个是更优方案。在你看来是扯淡的做法，在我看来恐怕是更合适的，反之亦然。
      我们不能纯粹为了用什么而用什么，而应该考虑更优方案。就像hibernate很多地方用异常做程序流程控制，因为在它遇到的那些场景下可能是最合适的、效率最高的。对基础框架和类库来说，对效率的追求无论如何都不过分。当然我说的是更优方案，不是最优。因为只要去想去思考去验证应该总能找到更加合适的方案。有些时候明明有更优方案我们可能也会弃之不用，因为已有成熟的和熟悉的方案一直在用，我们成了习惯，而采用不熟悉的方案即使它是更优的，我们可能也不敢用，因为采用一种不熟悉的技术，不了解的架构需要承担更大的风险，在以安全稳定为第一或以完成任务为第一的情况下还是采用保守的方案更好一些，即使方案差一些至少不容易出错。

通过返回值而非异常来表明运行中的非正常情况，我想到了C语言。C语言没有异常机制。而Java有异常机制。其实，不用异常，我们确实也可以用返回值来代替，并且程序是可以运行。不过，这应该是语言的向后发展而不是向前发展。
还有一种情况：在spring管理的事务中，你调用一个方法，这个方法处于事务中，如果这个方法正常执行完毕了，那么事务会提交；如果这个方法运行中出现了异常，事务自动回滚。如果用返回值来替代异常，那么，我们只能是手动去控制事务的提交与回滚了。

我不会再回复这个问题了，楼上完全没仔细思考我上面的回复。其实你说的跟我之前回复的内容并不完全是一回事