大多数时候不该在方法里直接try-catch IOException，除非能在当前上下文真正处理（如重试、降级、返回默认值）；否则掩盖问题，导致调用方无法感知失败，引发后续脏数据或空指针等问题。
Java中该不该在方法里直接try-catch一个IOException
大多数时候不该。除非你能在当前上下文真正处理它——比如重试、降级、记录后返回默认值；否则只是把异常吞掉或转成RuntimeException，反而掩盖问题根源。
常见错误现象：catch (IOException e) { e.printStackTrace(); } 后继续执行，调用方完全不知道文件读取失败，后续逻辑用null或脏数据计算。
- 使用场景：只有当前方法能决定“出错了怎么办”，才捕获。例如缓存加载失败时返回空列表，而不是让整个HTTP请求500
- 参数差异：检查是
IOException（受检）还是NullPointerException（非受检）——前者强制你面对，后者靠测试和逻辑防御 - 性能影响：频繁
try-catch本身开销不大，但掩盖异常会导致更难定位NPE、ArrayIndexOutOfBoundsException这类本该早暴露的问题
什么时候适合用异常驱动流程（Exception-driven Flow）
极少。只适用于语义上“异常=预期外的业务分支”，且该分支发生概率极低、处理成本远高于提前判断。
典型反例：new File(path).exists() 比 try { new FileInputStream(path); } catch (FileNotFoundException e) { ... } 更清晰、更快、不依赖异常机制做流程控制。
立即学习“Java免费学习笔记（深入）”；
- 合理场景：解析第三方API返回的JSON，字段缺失时抛
JsonParseException，你捕获后返回Optional.empty()——因为字段是否存在无法静态预判 - 容易踩的坑：用
NumberFormatException代替String.matches("\d+")校验数字字符串，既慢又模糊意图 - 兼容性影响：JDK 17+ 的
SecurityManager废弃后，部分异常驱动的权限检查逻辑已失效，别再依赖
throws声明太多是不是设计坏了
是信号，但不一定是坏。关键看谁该负责处理。
常见错误现象：Service层方法签名堆满throws SQLException, IOException, JsonProcessingException，Controller里全塞try-catch，结果每个接口都写一遍日志+统一错误码封装。
- 改进方向：把底层异常转为领域异常（如
OrderNotFoundException），在DAO/Client层就转化，Service只声明业务相关异常 - 参数差异：
throws Exception是红线；throws DataAccessException（Spring）可接受，因为它抽象了具体技术细节 - 性能影响：异常对象创建本身有开销，但比起错位的异常传播导致的调试时间，这点开销几乎可以忽略
为什么团队里总有人爱在工具类里catch所有异常并return null
因为他们把“不让程序崩溃”当成了最高目标，忽略了调用方需要知道“为什么得不到结果”。
最麻烦的不是写法本身，而是这种习惯会传染：下游开发者看到StringUtils.isEmpty(str)可能返回false却没报错，就默认所有工具方法都安全，直到某次str是未初始化的byte[]，触发ArrayStoreException才暴露。
- 真实代价：线上查bug时，堆栈里看不到原始异常，只能靠日志猜——而那个工具方法的日志可能只写了“input is null”，根本没提它吞掉了
OutOfMemoryError - 底线做法：至少记录
log.warn("Unexpected exception in parseDate, returning null", e)，且确保e是原始异常，不是new RuntimeException(e)套娃 - 更优解：工具方法不捕获，让调用方决定；或者提供
safeParseDate(String, Supplier<Date> fallback)显式支持兜底
catch前，能不能三秒内说出“我拦下它，是为了让谁、在什么条件下、做什么事”。 
