绝大多数情况下是偷懒写法——它会吞掉本该单独处理的异常，掩盖编程错误，导致线上问题难以定位，仅应在顶层兜底时使用且须记录完整堆栈并上报监控。

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) 里——这比不检查还糟。

关键判断点：这个异常是否属于当前方法「有能力且应该处理」的范畴？

• 数据库连接失败 → 应由 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，那再精细的异常分类也白搭。