业务代码报错却无日志记录，是什么原因导致的？

业务代码异常排查：日志缺失之谜

本文分析一段代码，该代码使用双层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”。然而，日志中缺失该信息，问题并非代码逻辑错误，而是日志记录机制问题。

可能原因及排查步骤：

1. 日志级别设置: 检查日志配置，确保日志级别允许记录log.error级别的信息。如果日志级别设置为warn或info，则log.error级别的日志将被忽略。

2. 日志输出目标: 验证日志输出目标的正确性。确认日志文件路径是否存在、数据库连接是否正常，以及日志是否正确输出到指定位置。

3. 日志系统故障: 排查日志系统本身是否存在故障，例如磁盘空间不足、日志文件已满、日志系统服务异常等。

4. 异常类型及处理: 仔细检查“业务代码1”，确定是否真的抛出了Exception。某些异常可能被业务代码1内部消化，并未真正抛出。 检查异常类型，并打印异常的堆栈信息，以便更准确地定位问题。

5. log 对象: 确认log对象是否正确初始化并配置。

通过以上步骤，系统地排查日志记录机制和“业务代码1”的异常处理，即可找到日志缺失的原因，并解决问题。 如果问题仍然存在，请提供“业务代码1”的具体内容以便进一步分析。