应避免用 try-catch 包裹整个 main 方法，因其掩盖编程错误、吞没未检查异常导致资源泄漏与状态不一致；需精准捕获已知可恢复操作，优先防御性校验；自定义 BusinessException、SystemException、FatalException 分层表达语义；资源清理首选 try-with-resources；日志须含上下文、脱敏敏感信息并打印异常链。
为什么 try-catch 不能包住整个 main 方法
把所有逻辑塞进一个 try-catch 块里看似“兜底”，实际会掩盖问题根源，让 NullPointerException、ArrayIndexOutOfBoundsException 这类本该在开发阶段暴露的编程错误，变成运行时难以定位的静默失败。
更严重的是，它会吞掉未检查异常（unchecked exceptions），导致资源泄漏（比如 FileInputStream 没关闭）、状态不一致（比如事务中途崩溃但没回滚）。
- 只对**已知可能失败且能合理恢复**的操作做捕获，例如网络请求、文件读写、JSON 解析
- 对
RuntimeException及其子类（如IllegalArgumentException），优先用防御性编程提前校验，而不是等抛出来再 catch - 必须确保
catch块里有明确动作：记录日志（含上下文变量）、返回默认值、重试或向上抛出封装后的业务异常
如何用自定义异常区分“可恢复”和“该熔断”的错误
Java 默认异常体系不带语义，IOException 既可能是磁盘满，也可能是网络抖动。混用会导致上层无法决策：是重试？降级？还是直接告警？
建议按故障性质分层定义异常：
立即学习“Java免费学习笔记（深入）”；
-
BusinessException（运行时异常）：用户输入非法、余额不足等业务规则拒绝，前端可直接提示 -
SystemException（受检异常或运行时）：数据库连接超时、下游服务不可用，需触发重试/降级逻辑 -
FatalException（运行时）：JVM 内存溢出、类加载失败，不应被捕获，而应由监控系统捕获并告警
关键不是多建类，而是让 catch (SystemException e) 这样的代码能立刻传达意图——这里要走容错流程，不是随便打个日志就完事。
finally 和 try-with-resources 哪个更适合资源清理
finally 看似灵活，但容易漏写或写错：比如在 finally 里又抛异常，会覆盖原始异常；或者忘记判空就调 close()，反而引发新异常。
try-with-resources 是编译器保障的确定性清理，只要资源实现 AutoCloseable（JDK 7+ 大部分 IO 类都已实现），就能保证即使发生异常也会执行 close()。
- 优先用
try (FileInputStream fis = new FileInputStream(...)) { ... } - 避免在
try-with-resources的资源声明中调用可能抛异常的方法（如new Socket(host, port)），否则异常会打断资源初始化，导致后续close()不被执行 - 若需多个资源，用逗号分隔，它们按声明逆序关闭（后声明的先关），这点影响连接池、嵌套流等场景的正确性
log.error("failed", e) 为什么经常不够用
只打堆栈不记录关键上下文，等于给运维扔了个谜题。同一个 SQLException 在订单创建和库存扣减里含义完全不同，但日志看起来一模一样。
真正有用的异常日志必须包含三要素：发生了什么、在哪儿发生的、当时关键数据是什么。
- 用 SLF4J 的占位符格式：
log.error("order payment failed for user {}, order {}", userId, orderId, e) - 对敏感字段（如手机号、身份证）做脱敏再记录，避免日志泄露隐私
- 在 catch 块里不要只打日志就吞掉异常；如果选择不抛出，必须有明确补偿动作（如发消息通知、写失败表）
最常被忽略的一点：异常链（getCause()）可能比顶层异常更重要，某些框架（如 Spring JDBC）会把原始 SQL 错误包装好几层，不遍历打印就找不到真实原因。
