業務代碼異常，日志缺失：如何排查“報錯信息1”去哪了？

排查業務代碼異常：日志缺失分析

在日常開發中，我們經常遇到這種情況：代碼運行異常，但預期錯誤日志卻不見蹤影。本文通過一個案例分析，探討可能原因及排查方法。

案例代碼片段：

try {     List<Plan> plans = planService.lambdaQuery()             .eq(Plan::getYn, YnEnum.YES.getLabel())             .eq(Plan::getStatus, Plan.Status.DONE.getCode())             .isNotNull(Plan::getPId)             .list();     List<List<Plan>> 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); }

代碼使用雙層try-catch塊。外層捕獲planService.lambdaQuery()及后續異常，記錄“報錯信息2”；內層捕獲“業務代碼1”異常，記錄“報錯信息1”。問題是：“業務代碼1”異常存在，但日志中缺失“報錯信息1”。

這并非代碼邏輯錯誤，而是日志記錄機制可能存在問題。如果“業務代碼1”拋出異常，內層catch塊捕獲并執行log.error(“報錯信息1：”, exception);。日志缺失，需檢查以下幾點：

1. 日志級別配置: 確認日志系統是否允許記錄log.error級別日志。如果級別設置為warn或更高，error級別日志將被忽略。
2. 日志輸出目標: 檢查日志輸出目標（文件、控制臺）配置是否正確，是否有寫入權限。日志文件是否已滿？ 文件路徑是否正確？
3. 日志框架問題: 檢查日志框架本身（例如logback, log4j）是否正常工作，是否存在配置錯誤或框架本身的bug。
4. 異常被吞沒: 雖然代碼有catch塊，但catch塊內部可能存在未處理的異常，導致異常被靜默處理，沒有被日志記錄。 檢查catch塊內部是否有其他異常拋出或被忽略。
5. 異步日志: 如果日志記錄是異步的，可能由于異步線程池滿或者其他異步問題導致日志丟失。

通過檢查以上幾點，就能找到“報錯信息1”缺失原因。只有確認日志記錄機制正常工作，才能進一步分析“業務代碼1”的邏輯問題。 建議添加日志輸出到控制臺，以便快速排查問題。 同時，檢查日志框架的運行狀態以及相關的配置文件。