绝大多数情况下是偷懒写法——它会吞掉本该单独处理的异常，掩盖编程错误，导致线上问题难以定位，仅应在顶层兜底时使用且须记录完整堆栈并上报监控。
catch (Exception e) 是不是偷懒写法
绝大多数情况下是——它会吞掉本该被单独处理的异常，比如 IOException 和 SQLException 的恢复策略完全不同，统一用 Exception 捕获后，你既没法针对性重试，也容易掩盖空指针、数组越界这类编程错误。
常见错误现象：catch (Exception e) 后只打一行日志甚至直接 e.printStackTrace()，导致线上出问题时无法区分是网络超时还是逻辑 bug；更隐蔽的是，它会让编译器绕过对受检异常（checked exception）的强制处理提醒。
- 仅在顶层兜底时可用（如 Servlet 的
doGet、Spring 的 @ExceptionHandler），且必须记录完整堆栈 + 上报监控 - 绝不用于中间业务方法内部，尤其不能替代具体异常类型捕获
- 如果真要“通用捕获”，优先考虑
catch (RuntimeException e)，把受检异常留给调用方显式处理
受检异常（Checked Exception）到底该不该抛
Java 设计初衷是让开发者直面可能失败的 I/O、网络、SQL 等操作，但滥用会导致方法签名膨胀、调用链层层 throws、最终还是被塞进 catch (Exception e) 里——这比不检查还糟。
关键判断点：这个异常是否属于当前方法「有能力且应该处理」的范畴？
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 数据库连接失败 → 应由 DAO 层捕获并转为自定义异常（如
DataAccessException），上层服务决定重试或降级 - 文件不存在 → 如果是配置文件，应启动失败；如果是用户上传，应返回友好提示，而不是把
FileNotFoundException往上扔 - 第三方 SDK 抛出的受检异常，优先封装为运行时异常（
RuntimeException子类），避免污染业务代码
自定义异常怎么设计才不白费功夫
起个 MyServiceException 类名、继承 RuntimeException、空参构造函数——这种写法等于没写。真正有用的自定义异常必须携带上下文，且能驱动后续行为。
使用场景：支付回调验签失败、库存扣减超限、分布式锁获取超时等需要差异化响应的环节。
- 至少提供两个构造函数：含错误码 + 原始异常（
new BizException(ErrorCode.STOCK_INSUFFICIENT, e)） - 错误码必须可枚举（
enum ErrorCode），禁止字符串硬编码 - 避免在异常消息里拼接敏感数据（如用户手机号、订单号），日志脱敏由统一拦截器做
- 不要为了“分类”而多层继承，平铺 5–8 个业务异常类比搞出
BaseBizException → ServiceException → PaymentException → AlipayException更实用
try-with-resources 和 finally 的边界在哪
try-with-resources 解决的是资源泄漏，不是异常处理逻辑。别指望它帮你 catch 异常，它的 close() 抛异常还会被压制（suppressed）——除非你主动调用 getSuppressed()。
性能影响：JDK 7+ 编译后和手写 finally 几乎无差别，但语义更清晰；注意某些老框架（如早期 MyBatis）的 SqlSession 不实现 AutoCloseable，不能直接用。
- 所有实现了
AutoCloseable的资源（InputStream、Connection、Lock）优先用 try-with-resources -
finally只用于必须执行的清理动作（如解锁、重置标志位），且里面也要 try-catch，否则会覆盖主流程异常 - 不要在
catch块里手动close()，资源可能根本没初始化成功，判空又冗余——交给 try-with-resources
最常被忽略的一点：异常的粒度最终服务于可观测性。如果你的日志系统无法按异常类型聚合告警，或者监控大盘里全是 java.lang.Exception，那再精细的异常分类也白搭。
