最近在重新整理老系统的业务，基于老平台开发新的业务。看到一段关于财务退款的处理，很开心，这不就是我一直在找的核心处理模块吗。看一下出入参以及大致逻辑，决定复用。三下除以两下，调用业务，打印日志，OK，测试。然而，测试一跑，便是相当尴尬，而且越跑越尴[/强颜欢笑]
先是日志一段刷没有看到异常堆栈，退款单据也成功了，但是快递费用没有退，即退款明细没处理完，单据成功了。WTF，这不是事务没回滚吗，可是没异常呀，是不是异常被吃掉（捕捉）或者被什么条件过滤掉了。review了一下代码，发现：增强for循环里面更新集合数据，那么该出场的 java.util.ConcurrentModificationException堆栈呢？捕捉异常看了一下，是：e.getMessage()......诶，grep搜索一下日志，真心有一行日志是这个异常，但是不好发现，日志的打印还需要规范引发思考......
一、关于Exception日志打印心得，总结记录收集一下：
（1）打印日志堆栈要清晰：打印日志要打印出异常堆栈，尽量避免e.getMessage()打印，业务可处理异常除外。
（2）注意吃掉异常事务不会滚：异常导致的需要回滚事务要记得抛出异常，不要吃掉异常导致事务不会滚。
（3）该细化异常类型时细化，避免泛化：此做法在于支持不同的处理和恢复措施，业务异常和其他费业务运行时异常区分开，易于代码调试。这个细化要注意子类异常的处理块必须在父类异常处理块的前面，否则会发生编译错误。
（4）延迟捕捉异常：如果本段代码还没有能力处理异常，尽管抛出让调用方决定，目的在于准确处理。但也要注意避免异常转化过程丢失信息。
（5）异常处理框架:对于一个应用系统来说，有自己的一套异常处理框架，当异常发生时，就能得到统一的处理风格，将优雅的异常信息反馈给用户。
（6）用Json、Gson的打印时避免出现堆溢出java.lang.*Error：主要@manyToOne和@oneToMany的注解，主子级联，打印时相互寻找引起死循环，从而出现不该出现的打印异常，屏蔽了该关注的异常。

二、其次，就是上面提到的关于java.util.ConcurrentModificationException异常：使用增强 for 循环（这个语法糖解糖的结果其实迭代器遍历）遍历元素，并尝试删除增加其中的元素会触发fail-fast机制，即快速失败，它是 Java 集合的一种错误检测机制。当多个线程对集合（非fail-safe 的集合类）进行结构上的改变的并发操作时，有可能会产生 fail-fast 机制，这个时候就会抛出ConcurrentModificationException（当方法检测到对象的并发修改，但不允许这种修改时就抛出该异常）。同时需要注意的是，即使不是多线程环境，如果单线程违反了规则，同样也有可能会抛出改异常。把出现这个异常的代码改成普通循环即不会触发这个错误检测机制，但是要注意不要漏处理元素，因为删除下标的改动。
三、最后补一下关于事务不生效的日常发现：
（1）吃掉异常：没有异常事务当然不生效。
（2）事务方法私有private也会导致事务不生效，这应该时切面AOP定义的限制。
（3）同一个类中, 一个nan-transactional的方法去调用transactional的方法, 事务也不会效：spring是采用动态代理机制来实现事务@Transactional控制，而动态代理最终都是要调用原始对象即调用方的，而原始对象（没有携带事务信息）在去调用方法时，是不会再触发事务的。所以一个没有事务的方法去调用有事务的方法，事务也不会生效，重点在于源对象有无事务信息。
解决①把事务方法抽取出去另外一个服务类，通过注入给调用方调用。
解决②调用方获取代理对象去调用事务方法，避免用源对象去直接调用：声明一下，以下截图来源：https://blog.csdn.net/m0_38027656/article/details/84190949