我为什么反对用异常做流程控制？( 二 ) 曲总技术琐话“懒”是驱动程

为了让代码不那么丑陋，自定义的异常通常继承自RuntimeException 。在接口提供方和调用方没有通过介质(接口设计文档/对话...)充分沟通清楚的情况下，一个神不知鬼不觉的Runtime异常完全可能造成自身业务逻辑的无法自恰；

异常具有正常应答无法比拟的分层穿透性，也就是不管间隔多少层，都可以直接穿透到接入层。对于某些异常场景下的代码实现确实有很好的支撑，反之，成也萧何败萧何，这种强力的穿透能力是否会让逻辑失控， totally count on you and your team；

【我为什么反对用异常做流程控制？】综合上面的这些点，异常作为非常规的设计路数，在没有足够的把控能力下，千万不要无尽蔓延，这种类似“GoTo”式的代码实现，可能会让你的系统支离破碎。
我的态度
任何的系统架构设计，都是在不断的在做天人交战，利弊权衡。鲜有绝对的对与错，只有在当前组织环境内相对的合理与不合理。对于异常用作流程控制这件事，我是投反对票。因为即使异常的性能损耗对我们大部分的业务场景可以忽略不计的，但异常在接口中的易被忽视性、不可控的穿透性，就算是高素质的团队也不一定能完全消除这种风险。既然风险如此大，宁肯让团队按部就班老老实实的写好每一种应答。
承篇头的论点，重新展开再抽象归纳一下：
任何逻辑判断的流程控制都不应该用异常来实现，除非那些能明确导致程序中断/终止的节点。异常务必要明确抛checked还是unchecked ，对调用者负责。