java捕获异常需目的明确：兜底日志或统一响应应在框架边界（如spring全局处理器）进行，记录类型、堆栈及上下文；禁用catch(throwable)和静默吞异常；资源操作用try-with-resources；多异常用multi-catch且类型不可继承。
Java 中捕获“所有异常”不能简单写成 catch (Exception e) 或更糟的 catch (Throwable t)，而应根据场景明确意图：是兜底日志、统一响应，还是资源清理？规范写法关键在**目的清晰、不掩盖根因、不越权处理**。
只在明确设计为“泛化处理”的位置兜底
业务逻辑层通常不该捕获 Exception。它适合出现在框架边界或统一入口处，比如 Spring 的全局异常处理器、Servlet 的 Filter、或 RPC 接口的最外层 try 块：
- 必须记录完整异常类型（用
e.getClass().getSimpleName()）、堆栈和上下文（如请求 ID、参数摘要） - 禁止静默吞掉：
catch (Exception e) { log.warn("未知异常", e); return errorResponse(); } - 避免在兜底块中做重试、回滚等具体动作——那些应由更具体的 catch 处理
绝对不要用 catch (Throwable t)
Throwable 包含 Error（如 OutOfMemoryError、StackOverflowError），它们代表 JVM 严重故障，程序已无法可靠继续：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 捕获后仅 log 并立即 re-throw，或直接让 JVM 终止（更安全）
- 业务代码里出现
catch (Throwable)属于高危代码，CI/CD 应拦截 - 若真需监控（如 APM 工具），也必须先判断
t instanceof Error并特殊处理
配合 try-with-resources 防资源泄漏
即使要做兜底，只要涉及 I/O、数据库连接等资源，就必须用 try-with-resources 替代手动 close：
- 资源自动关闭，且关闭异常会作为 suppressed 异常附加到主异常上
- 排查时调用
e.getSuppressed()查看被抑制异常，避免遗漏真实根因 - 示例：
try (FileInputStream fis = new FileInputStream("a.txt")) { ... } catch (IOException e) { ... }
多异常捕获优先用 multi-catch，但注意继承关系
当几种异常需统一处理（如都记录日志+返回 500），用 Java 7+ 的 multi-catch：
- 写法：
catch (IOException | SQLException | IllegalArgumentException e) - 竖线分隔的类型必须互不继承；
Exception | RuntimeException编译报错 - 异常变量
e是 final，类型是这些异常的最小公共父类（如Exception）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
