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

居然没人回了。
为什么？
怎么回事？

你为什么用oo？
因为我可以对目标域分类，让开发井井有条。

你为什么用异常控制业务流？
因为我可以让各种错误交织。

仅仅基于主键的应用很少，即使k-v这样的nosql，多数也提供了index，省下来的是sql解析和执行计划评估开销
我是电信行业，没从事过互联网，但我相信这些企业的crm，工单、erp、供应链、cmdb都是直接或者间接来自企业解决方案，这些系统应该都是索引外键从生的系统
异常最优异的特性在于上溯和异常情况下的对象析构，这是errorcode绝对无法带来的优点
异常代替出错code是编程的一个巨大进步，实际上这是进化出来的体系，而且实现相当复杂
异常使得你可以很容易并且在编译期就能意识到应该处理那些问题，包装每一层的功能，并且使得每层的正常逻辑和异常逻辑分离，并且尤其在c++，它能让你不用管理异常导致的内存泄漏
多数公司都是因为自身使用不当和开发简便原因不使用索引或者外键
而那些互联网巨头业务上要用索引而采取自己实现，实际就是拿人力成本博取扩缩性能

这么说太片面。是否用约束取决于项目的类型。商业数据有多重要也取决于商业的类型。大型互联网项目大部分都是不一致满天飞的。数据的正确性取决于对“正确的定义”。试想一个植入心脏的数据库收集来自身体的反应信息，对于它来说，迟到的数据就是致命的。

我的观点就是lz太初级啊后面那些话

你如果做一个超大型系统，好多模块，好多人开发，分好多层，如果用ErrorCode不得烦死。

都说了不要用异常控制程序流程

帅锅，你没仔细看我的主帖和我回的帖。
         定位错误，用errorcode确实不如异常方便。但我要讨论的主题是应不应该用异常控制正常的业务流程走向。
         你正常业务流程和运行期非正常状况都用异常处理，不觉的乱？
         另外项目达到一定规模，用异常控制业务流程走向你一样得定义很多很多的异常。
         最后，我再说一遍，我要讨论的主题是业务状态码和异常控制业务正常流程哪个方式更好。不是讨论程序的非正常状态发生时用错误码和异常哪个更好

关于外键该不该用，也是一个争论很多的话题，很多情况下确实因为外键问题导致的导入数据出错等问题，也确实会因为创建了太多的数据库约束导致数据库效率降低。
我想再单开一帖讨论数据库约束、数据表设计方面的话题。发了帖欢迎您来拍。
对于异常与errorcode相比带来的优势，我非常赞同您的观点。
但是我开这个帖的本意是要讨论一下，对于正常业务流程，使用异常还是使用业务状态码更好；而不是要讨论错误码和异常哪种方式控制非正常程序状态更好。

异常你应该理解为也是当前业务的一种状态
比如说文件不存在，表不存在，链接失败，这也是你面临业务中的一种可能
但这种状态实际是你调用那层无法控制的情况，而可能是你上级可以处理的
所以这是你应该向上级反映的，而且反应的东西如果有栈信息，异常对象附加内容，这些都会更好帮助定位问题，一个errorcode对于这种处理则太弱，而且不能做到跳转（长跳短跳都做不到）

这正是我前面说过的，这些属于程序运行时的非正常情况，理应使用异常处理。
而像登录用户名输入错误，密码错误，注册用户名已存在，用指定查询条件得到空结果集等应作为程序运行时的正常现象处理，这种时候不应用异常处理，而应该作为正常的业务逻辑出现在代码中。这种时候使用异常就不合适了。