没有绝对，没有百分百

finally的执行

finally不是百分百都执行。finally一般在try内的最后执行，一般用来释放资源用。

finally不执行的情况：

• try没执行的话，自然不会执行finally
• 遇到虚拟机中断，则finally不执行。System.exit(1);会中止当前运行中的jvm
• 非守护线程中止时，则守护线程里的finally不会被执行。

2013年的时候，与项目组里的架构师讨论程序设计时，有提到finally里资源释放的问题，他说自己的程序不会因任何意外而产生问题。当时，我只是硬生生的拿质量管理里的6西格玛理论跟他辩驳，却没有说服他。人的认知是在不断拓展的。近期，这位架构师，已经出书了，把自研的数据控制框架结合阴阳八卦学整理成册，看了其中一段，感觉很有道理。

ClassCastException

对于类继承，派生类拥有基类的所有成员，意思为：派生类 is a 基类。假如AVo extends BaseVo，则当 BaseVo clz=new AVo();时，clz可以转换成AVo。而 (AVo)new BaseVo() 这种转换，就会引发ClassCastException。

当一个基类有多个派生类时，在做类型转换时，可以先用instanceof来判断一下，以规避ClassCastException。

 

“没有”与“没有找到”是两回事！

运营反馈了一个bug。转正不久的程序媛排查了一段时间，然后郁闷地来找我求助，信誓旦旦地说没有相关逻辑，疑惑不解的是为什么会出现运营所反馈的bug。是呀！如果没有相应的逻辑，不应该出现那样的bug。迟疑一会，然后，我跟她一起梳理代码，果不出意外，发现了出错的代码段。找到了出错的地方，自然就好修复了。

“没有”与“没有找到”可不是一回事。这位女同学因为没有找到，而下结论为没有，这么一个心理暗示，导致了自己越来越迷糊。尽早丢掉这样的“多米诺骨牌”，不管做什么事情，专著和耐心是你乘风破浪的双翼。

 

我的代码绝对不会出错

产品汪来找程序猿，反映说企业配置的数据不对，然后跟程序猿描述了一下企业客户的操作过程。程序猿小哥表示不买单，认为自己的代码不会出现产品汪所描述的问题，随即在测试环境向产品汪操作了一遍，没有复现出来。就反驳产品汪，义正言辞的强调自己的程序不会出错，绝对不会。产品汪灰溜溜的走了。过了一会，又回来了，在生产环境，同样的问题又出现了。 程序猿只得细心地逐行排查代码来定位求证，果然，还真发现问题了。

墨菲定律是经得起考验的。永远不要认为100%没问题。别人指出了问题，先反思一下自己，也许更靠谱。

 

for循环里要不要捕获异常

我们知道，在循环一个集合数据时，一旦处理某条数据出现异常，那么，整个循环将会中断。

那么，在遍历集合数据时，有必要加一个异常捕获，即使某一条出异常，不会导致整个循环中断。就像下面的伪代码。对于一些定时任务，通常这么做比较靠谱。比如定期调用三方接口查询当前支付中交易的支付结果。

不过，要注意了，这样做并非放之四海而皆准。有些场景，却需要一旦出现异常就要中断整个循环。

譬如，合并支付的场景，多条业务单对应一笔支付单。当支付单支付成功后，要修改对应的业务单状态。如果使用for循环来逐条修改的话，就不能在循环体里加异常捕获。这是一个完整的事务，要么都改，要么都不改。

for (Entity entity : list){
    try {
        ..业务处理..
    } catch(Exception e){
        log.error("当前数据处理异常，", e);
    }
}

 

 

数据表一定要有主键自增的id字段吗？

在基础业务数据表或业务关系表（中间表）中，最好不要有无意义的主键自增id。例如用户表，同时存在主键自增的id字段和业务唯一的user_id字段，反而会带来理解和维护的成本，不如简化数据模型，直接使用user_id作为主键。再例如银行通道表，同时存在主键自增的id字段和业务唯一的bank_code表，开发人员在开发相关业务时，如果需要用到并记录银行通道，就容易混淆id与bank_code，久而久之，就会出现某些表存的是银行通道的id，而某些表存的是银行通道的bank_code，产生系统熵增。同样的例如银行通道信息表、航司信息表、企业表、企业业务关系表、企业与渠道商关系表、企业配置表，etc.

另一种情况，对于订单表、结算表等涉及交易数据的大型表，建议添加主键自增的id字段。这样的设计决策有几个优点：

1. 快速插入：自增id字段可以确保每次插入新记录时都有一个唯一的标识符，避免了数据冲突。同时，自增id字段的值按照递增顺序生成，减少了插入操作时的索引维护开销，提高了插入数据的速度。

2. 高效索引：自增id字段通常会自动创建索引，这对于查询和排序操作非常有帮助。索引可以加快查询的速度，尤其是在涉及范围查询、连接查询或排序操作时。

3. 容易维护和管理：自增id字段作为主键，可以方便地进行数据的更新、修改和删除操作。通过主键定位到特定的记录，可以更高效地执行数据的修改操作。

4. 数据完整性：主键自增id字段可以确保每一条记录都有唯一的标识符，避免数据冗余或重复。这有助于维护数据的完整性和一致性。

虽然在大型交易类表中添加主键自增id字段可能会增加一些存储空间和维护成本，但这种折衷是值得的，因为它可以提高查询和修改数据的性能，提升系统的整体效率。

所以，我们在设计数据表或进行数据设计评审时，并不是一刀切地要求都加上或都不加上id字段。具体是否需要在表中添加id字段，应根据具体的需求和情况来进行评估和决策。

注意，上面说的是单体系统或单体数据库。在分布式系统中，使用全局唯一标识符（GUID）或分布式算法生成的标识符作为主键，而不是依赖于自增id字段。

 

▄︻┻┳═一想法随写：推动与拉动 and 百思得解 and 学会扭转被动局面 and 大胆假设小心求证

▄︻┻┳═一没有绝对，没有百分百