生产环境 try-catch 高频踩坑点（未用好带来的严重影响）

try-catch 写在 for 循环外 vs 循环内核心区别

一、try-catch 写在 for 循环内部（每次循环单独捕获）

代码示例

List<String> list = Arrays.asList("a", "b", null, "c");
for (String item : list) {
    try {
        System.out.println(item.length());
    } catch (NullPointerException e) {
        log.error("当前元素处理失败：{}", item, e);
        // 可以选择：continue / break / 重试
        continue;
    }
}

特点

1. 单个元素异常，不打断整个循环
   某一次迭代抛异常只会捕获当前这一轮，continue 后循环继续执行下一条数据，不会终止整个遍历。
2. 异常隔离粒度细
   业务上适合批量处理数据（导入文件、采集批量数据、循环调用第三方接口），部分数据失败不影响整体任务跑完。
3. 可针对单条失败做单独补偿、重试、记录失败数据。
4. 缺点：每轮循环都要创建异常捕获上下文，海量循环下有极轻微性能损耗（业务基本可忽略）。

适用场景

批量数据处理、批量入库、批量接口调用、文件逐行解析，允许部分数据失败，必须跑完全部数据。

---

二、try-catch 写在 for 循环外部（整个循环整体捕获）

代码示例

List<String> list = Arrays.asList("a", "b", null, "c");
try {
    for (String item : list) {
        System.out.println(item.length());
    }
} catch (NullPointerException e) {
    log.error("批量处理全部中断", e);
    // 循环直接终止，后面所有元素不再执行
}

特点

1. 任意一次迭代抛异常，整个循环立刻终止
   异常抛出后直接跳出for循环，循环内剩余未处理的元素全部跳过，不再执行。
2. 异常粒度粗，只能感知「整个批量流程失败」，无法区分哪一条数据出错。
3. 性能略优：仅创建一次捕获上下文，循环内无额外开销。
4. 若需要记录失败数据，无法在catch里拿到出错的单条item。

适用场景

循环内是强依赖流程，一条失败则整体流程无意义，必须全部终止 ：

例如：循环执行多步事务操作、链式初始化资源、分步校验，中间一步失败整体作废。

---

三、关键对比表

维度	try-catch 在 for 循环内	try-catch 在 for 循环外
异常影响范围	仅中断当前单次循环，后续继续执行	抛出异常直接终止整个循环，剩余元素不处理
失败数据处理	catch内能获取当前出错item，可单独记录/重试	无法直接拿到出错的单条数据
业务容错能力	高，部分失败不影响整体跑完	低，一错全停
性能损耗	轻微（每次迭代创建捕获上下文）	几乎无额外损耗
事务场景	单条独立事务，失败仅回滚本条	整体大事务，一条失败全部回滚

四、拓展两种混合写法（生产常用）

1. 内层捕获异常记录，外层兜底捕获致命异常

try {
    for (String item : list) {
        try {
            // 单条业务逻辑
        } catch (Exception e) {
            // 记录单条失败，继续循环
            log.error("单条数据失败:{}", item);
        }
    }
} catch (Throwable t) {
    // 捕获OOM、数据库连接耗尽等致命错误，直接终止任务告警
    log.error("批量任务发生致命异常，流程终止", t);
}

优势：普通业务异常单条跳过，系统级致命异常直接中断并告警。

2. 循环内捕获，标记失败次数，循环结束后统一告警

int failCount = 0;
for (String item : list) {
    try {
        doBiz(item);
    } catch (Exception e) {
        failCount++;
        log.error("处理{}失败", item, e);
    }
}
if (failCount > 0) {
    // 批量跑完后统一推送告警
    sendAlarm("本次批量共"+failCount+"条数据处理失败");
}

五、结合定时采集数据存储业务推荐写法

如果项目是定时批量采集数据，必须把 try-catch 写在循环内部：

• 某一个设备采集接口超时/报错，不能阻断剩下几十上百台设备采集；
• 单台失败单独打印日志、记录失败设备ID，便于排查；
• 循环跑完后统计失败数量统一告警。

错误示范（循环外捕获）：一台设备接口报错，剩余所有设备全部不采集，造成数据大面积缺失。

----------------------------------------------------------------------------------

以下是生产环境 try-catch 高频踩坑点（未用好带来的严重影响）

（一）错误1：超大范围裸捕获 catch(Exception) / catch(Throwable) 吞掉所有异常

反面代码

// 问题：不分异常类型，全部静默吃掉
try {
    batchCollectData();
} catch (Exception e) {
    log.error("采集失败"); // 只打印一句话，无堆栈
}

生产负面影响

1. 故障无法定位：只打印文字，无异常堆栈，不知道哪行代码、什么原因报错；
2. 掩盖致命异常：OOM、数据库连接耗尽、栈溢出、空指针全部被吞，定时任务/接口看似正常，实则数据大量丢失；
3. 业务异常被隐藏：本该告警的采集失败、第三方接口熔断，日志无特征，运维无法发现。

（二）错误2：只 catch 不打印异常堆栈 e

catch (IOException e) {
    log.error("调用接口失败"); // 没传e，丢失堆栈
}

影响

日志只有文字，看不到报错行号、异常链路，线上出问题只能盲猜，排查成本成倍增加。

（三）错误3：捕获后不做兜底补偿，直接忽略异常

catch (Exception e) {
    log.error("处理失败", e);
    // 无重试、无失败记录、无告警
}

影响

批量采集场景单条数据静默丢失，数据库缺数据，对账不平，业务长期故障无人感知。

（四）错误4：try 包裹无关代码，扩大捕获范围

try {
    // 无关初始化代码
    List<Device> list = deviceMapper.selectAll();
    // 真正可能报错的采集逻辑
    collectDeviceData(list);
    // 无关打印日志
    log.info("采集完成");
} catch (Exception e) {}

影响

本该正常的查询数据库代码报错也被捕获，本该中断流程的初始化失败被掩盖。

（五）错误5：finally 中抛出异常，覆盖 try/catch 的原始异常

try {
    httpClient.doGet();
} catch (Exception e) {
    throw new BusinessException("采集异常", e);
} finally {
    // 关闭流时抛出新异常，原始业务异常直接丢失
    inputStream.close();
}

影响

日志只会打印关闭流的异常，真正业务报错消失，完全误导排查方向。

（六）错误6：异步/定时任务中异常未捕获，导致线程永久死亡

以你之前 Spring @Scheduled、线程池场景举例：

1. 仅catch Exception，Error（OOM、StackOverflowError）未捕获；
2. 调度线程直接死亡，定时任务永久停止，无任何报错提示。

（七）错误7：循环内捕获异常但不终止事务，脏数据入库

@Transactional
public void batchSave() {
    for (Data data : list) {
        try {
            dataMapper.insert(data);
        } catch (Exception e) {
            log.error("插入失败", e);
        }
    }
}

影响

单条插入失败不回滚，部分成功、部分失败，数据库数据不一致，对账异常。

（八）错误8：捕获后重新抛异常丢失原始堆栈

catch (NullPointerException e) {
    // 错误：只传错误信息，丢失根因异常
    throw new BizException("数据为空");
}
// 正确：带上原始异常
throw new BizException("数据为空", e);

影响

上层日志只能看到自定义业务异常，看不到原始空指针堆栈，无法定位null对象。

（九）错误9：使用 return / break / continue 跳过 finally 资源释放

try {
    Connection conn = getConn();
    if (conn == null) {
        return; // 直接return，跳过finally，连接不释放，连接池耗尽
    }
} finally {
    closeConn();
}

影响

数据库、Redis、HTTP连接泄漏，线程池/连接池打满，整个服务阻塞卡死。

（十）错误10：捕获 RuntimeException 但漏检查受检异常

IO、SQL等受检异常单独抛出，外层未捕获，直接打断定时/接口流程。

二、使用 try-catch 必须遵守的核心注意事项

1. 精准捕获，拒绝大范围捕获

• 优先捕获具体异常 ：NullPointerException、IOException、SQLException、TimeoutException；
• 禁止直接 catch(Exception) 裸捕获，如需全局兜底，分层捕获：先捕获细分业务异常，最后一层兜底Throwable，区分业务错误与系统致命错误。

2. 打印日志必须传入异常对象 e

// 标准写法，保留完整堆栈
log.error("设备{}采集失败", deviceId, e);

3. 资源释放必须放在 finally / 使用 try-with-resources

IO流、数据库连接、Redis连接、Redisson分布式锁：

1. JDK7+ 优先 try-with-resources 自动关闭，避免finally抛异常；
2. 传统写法：finally 内判断非空再关闭，关闭逻辑自身加try-catch。

// 推荐：自动释放资源
try (CloseableHttpClient client = HttpClients.createDefault()) {
    // http请求
} catch (IOException e) {
    log.error("请求异常", e);
}

4. 异常分层处理，就近捕获，上层兜底

1. 内层（循环/单条业务）：捕获单条业务异常，记录失败数据、继续循环；
2. 外层（定时/接口入口）：兜底捕获Throwable，捕获OOM、Error等致命错误，推送告警、终止任务；

5. 抛出自定义业务异常时，必须携带根因e

catch (TimeoutException e) {
    // 正确：传递原始异常堆栈
    throw new CollectException("设备接口请求超时", e);
}

6. finally 内禁止抛出未捕获异常

关闭资源逻辑单独加try-catch，防止覆盖原始异常：

finally {
    if (conn != null) {
        try {
            conn.close();
        } catch (SQLException ex) {
            log.warn("连接关闭失败", ex);
        }
    }
}

7. 事务场景异常处理规范

• 单条独立事务：循环内捕获，本条失败回滚，其余继续；
• 批量整体事务：循环外放try-catch，任意失败全部回滚。

8. 定时/线程池异步任务兜底捕获 Throwable

Spring @Scheduled、自定义线程池任务最外层必须：

@Scheduled(cron = "0/10 * * * * ?")
public void collectTask() {
    try {
        // 全部业务逻辑
    } catch (Throwable t) {
        log.error("定时采集任务致命异常，任务终止", t);
        // 推送钉钉/短信告警
    }
}

避免Error杀死调度线程，定时永久停跑。

9. 捕获异常后必须有处理动作，不能只打印日志

可选处理动作至少一种：

1. 记录失败数据到失败表，后续补偿重试；
2. 定时推送告警通知运维；
3. 本地重试3次（接口超时场景）；
4. 返回友好业务码给前端。

10. 不要用异常做业务逻辑判断（性能差、可读性差）

反面：通过捕获空指针判断数据是否存在

// 不推荐
try {
    doc = expiringMap.get(key);
    doc.getDeviceId();
} catch (NullPointerException e) {
    // 数据不存在逻辑
}
// 推荐：先做if判空，异常仅处理真正意外错误
Document doc = expiringMap.get(key);
if (doc == null) {
    // 数据不存在
}

三、生产环境标准 try-catch 开发规范（直接落地）

规范1：分层捕获模板（定时批量采集通用）

@Scheduled(fixedRate = 60000)
public void batchCollect() {
    List<Device> deviceList = deviceMapper.selectOnlineDevice();
    int failCount = 0;
    // 外层兜底捕获致命Error
    try {
        for (Device device : deviceList) {
            // 内层精准捕获单条业务异常
            try {
                collectSingleDevice(device);
            } catch (TimeoutException e) {
                failCount++;
                log.error("设备{}采集超时", device.getId(), e);
                saveFailRecord(device.getId(), "接口超时");
            } catch (IOException e) {
                failCount++;
                log.error("设备{}网络异常", device.getId(), e);
                saveFailRecord(device.getId(), "网络错误");
            } catch (Exception e) {
                failCount++;
                log.error("设备{}未知采集异常", device.getId(), e);
                saveFailRecord(device.getId(), "未知异常");
            }
        }
        // 失败数量告警
        if (failCount > 0) {
            alarmService.sendWarn("本次采集共"+failCount+"台设备失败");
        }
    } catch (Throwable t) {
        log.error("采集任务发生致命异常，全部终止", t);
        alarmService.sendCritical("定时采集服务故障，请紧急处理");
    }
}

规范2：资源自动关闭模板 try-with-resources

// HTTP/文件/数据库连接统一使用
try (CloseableHttpResponse response = httpClient.execute(request)) {
    // 业务处理
} catch (HttpException e) {
    log.error("接口响应异常", e);
} catch (IOException e) {
    log.error("网络IO异常", e);
}

规范3：禁止写法黑名单

1. catch (Exception e) { log.error("出错"); } 无堆栈；
2. catch (NullPointerException e) { throw new BizException("空指针"); } 丢失根因；
3. try包裹几百行无关代码，捕获范围过大；
4. finally中直接close()不做内部try-catch；
5. 定时任务最外层无Throwable兜底捕获。

四、总结生产环境不用好 try-catch 整体危害汇总

1. 数据层面：批量采集丢失数据、数据库脏数据、对账不平；
2. 服务稳定性：连接泄漏、线程池耗尽、定时任务永久停止、服务卡死；
3. 运维排查：无异常堆栈、根因丢失，线上故障几小时定位不到；
4. 业务感知：故障静默发生，无告警，长期业务异常无人发现；
5. 性能隐患：滥用异常做逻辑判断，大量创建异常对象GC频繁。