业务代码异常排查：日志缺失之谜
本文分析一段代码，该代码使用双层try-catch块处理异常，但内层try-catch块捕获的异常信息却未记录到日志中。
代码片段如下：
try {
List plans = planService.lambdaQuery()
.eq(Plan::getYn, YnEnum.YES.getLabel())
.eq(Plan::getStatus, Plan.Status.DONE.getCode())
.isNotNull(Plan::getPId)
.list();
List> partition = Lists.partition(plans, 5);
partition.forEach(planList -> {
try {
//业务代码1.....
} catch (Exception exception) {
log.error("报错信息1：", exception);
}
});
} catch (Exception exception) {
log.error("报错信息2：", exception);
} finally {
log.info("释放requestId[{}]的锁", requestId);
Redis.unlock(Module.REFRESH_PROMOTE, workerLockKey, requestId);
}
代码逻辑上，“业务代码1”发生异常，内层catch块应捕获并记录“报错信息1”。然而，日志中缺失该信息，问题并非代码逻辑错误，而是日志记录机制问题。
可能原因及排查步骤：
-
日志级别设置: 检查日志配置，确保日志级别允许记录
log.error级别的信息。如果日志级别设置为warn或info，则log.error级别的日志将被忽略。 -
日志输出目标: 验证日志输出目标的正确性。确认日志文件路径是否存在、数据库连接是否正常，以及日志是否正确输出到指定位置。
-
日志系统故障: 排查日志系统本身是否存在故障，例如磁盘空间不足、日志文件已满、日志系统服务异常等。
-
异常类型及处理: 仔细检查“业务代码1”，确定是否真的抛出了
Exception。某些异常可能被业务代码1内部消化，并未真正抛出。 检查异常类型，并打印异常的堆栈信息，以便更准确地定位问题。 -
log 对象: 确认
log对象是否正确初始化并配置。
通过以上步骤，系统地排查日志记录机制和“业务代码1”的异常处理，即可找到日志缺失的原因，并解决问题。 如果问题仍然存在，请提供“业务代码1”的具体内容以便进一步分析。
