java异常处理四大误区：一是空catch块吞异常，应记录完整堆栈并明确后续行为；二是泛捕exception/throwable，应按需捕获具体类型；三是finally中抛异常掩盖主异常，推荐try-with-resources；四是异常与业务逻辑混杂，需分层处理并分类自定义异常。
Java中try-catch看似简单，但实际编码中常因理解偏差或习惯问题埋下隐患。最核心的问题不是“会不会写”，而是“为什么这么写”没想清楚——比如吞掉异常、裸catch Exception、在finally里抛异常等，表面能运行，实则让问题更难定位、系统更不可靠。
误区一：空catch块（“吞异常”）
这是最危险也最常见的错误：捕获异常后什么也不做，甚至只打一行日志就结束。
- 后果严重：程序看似正常，但逻辑已中断，下游可能拿到null或脏数据，排查时毫无线索
- 正确做法：至少记录完整堆栈（e.printStackTrace()不够，要用logger.error("描述性信息", e)），并明确后续行为——是重试、降级、还是向上抛出
- 例外情况极少：仅当100%确定该异常可安全忽略（如某些IO流关闭时的已关闭异常），且必须加清晰注释说明原因
误区二：用Exception或Throwable泛捕获
写成 catch(Exception e) 或更糟的 catch(Throwable t)，看似省事，实则掩盖问题本质。
- 丢失类型语义：无法区分是业务异常（应提示用户）、系统异常（需告警）还是编程错误（如NullPointerException，该修复代码而非捕获）
- 干扰正常流程：比如把本该由调用方处理的受检异常（IOException）和不该捕获的Error（OutOfMemoryError）混在一起处理
- 建议：按需捕获具体异常类型；多个同类异常可用多catch（Java 7+）；对非预期异常，不如不捕，让其冒泡终止当前流程并触发监控告警
误区三：在finally里执行可能抛异常的操作
常见于资源关闭场景：在finally中调用close()，而close本身可能抛IOException，导致原始异常被覆盖。
立即学习“Java免费学习笔记（深入）”；
- 后果：真正出问题的地方（比如read()失败）被close()的异常掩盖，日志里只看到“关闭失败”，根因消失
- 解决方案：用try-with-resources（推荐），或在finally中对close()做二次try-catch并单独记录；绝不让finally里的异常影响主流程异常传播
- 小技巧：JDK7+中，AutoCloseable资源优先用try-with-resources，它自动处理了抑制异常（suppressed exception）的记录
误区四：异常处理与业务逻辑混杂，缺乏分层意识
比如DAO层捕获SQLException后直接弹窗提示用户，或Service层把所有异常都转成自定义异常却不区分场景。
- 违反关注点分离：数据层不该关心UI，表现层不该处理事务回滚
- 正确分层：DAO抛原始或包装后的数据异常 → Service捕获并决定是否重试/回滚 → Controller统一处理并转换为用户友好的响应（如HTTP状态码+提示文案）
- 补充：自定义异常要有明确分类（BusinessException / SystemException），并携带上下文信息（如订单ID、操作人），便于追踪
基本上就这些。异常不是用来“摆平”的，而是用来“沟通”的——和开发者、运维、监控系统沟通发生了什么、有多严重、该怎么响应。写得越随意，后期维护成本越高。
