Java中无“流程控制异常分支”概念；if/switch用于逻辑判断，try-catch用于异常兜底；应优先用条件语句规避可预知错误，如判空再解析、校验索引再访问。
Java 中没有“流程控制异常分支”这个标准概念。流程控制语句（如 if、switch）本身不产生异常，也不属于异常处理机制；而异常处理（try-catch-finally）是独立的运行时错误响应机制。两者可以配合使用，但需明确分工：条件语句负责业务逻辑判断，异常处理负责意外情况兜底。
条件判断优先于异常捕获
多数场景下，应先用 if 等条件语句主动规避可预知的非法状态，避免触发异常。这更高效、更清晰。
- 比如读取用户输入的整数前，先检查字符串是否为空或仅含空白符：if (str == null || str.trim().isEmpty())，而不是直接调用 Integer.parseInt(str) 然后 catch NumberFormatException
- 访问数组前判断索引范围：if (index >= 0 && index ，比放任 ArrayIndexOutOfBoundsException 再捕获更合理
- 对可能为 null 的对象调用方法前，先用 if (obj != null) 检查，而非依赖 NullPointerException 捕获
在 catch 块中嵌入条件逻辑做差异化恢复
当异常确实发生后，可以在 catch 块里用 if 判断异常类型或具体信息，执行不同恢复策略。
- 同一 try 块可能抛出多种异常，用 instanceof 或 e.getClass().getSimpleName() 区分处理
- 对 IOException，可判断是网络超时还是文件不存在，分别重试或提示不同错误信息
- 捕获 SQLException 后，解析 getSQLState() 或错误码，决定是回滚事务还是记录告警
不要用异常替代条件分支
把正常业务路径（如“用户未登录”“余额不足”）靠抛出自定义异常来驱动流程，属于反模式。
立即学习“Java免费学习笔记（深入）”；
- 异常机制开销大，频繁抛/捕获影响性能
- 代码可读性差，调用方难以预期哪些“异常”其实是常规业务结果
- 应改用返回值（如布尔值、枚举、Optional）或 if 显式判断，例如：if (!user.isAuthenticated()) { ... } 而非 throw new NotLoggedInException()
try-with-resources 中结合条件确保资源安全
在自动资源管理中，可在 try 块内用 if 控制资源使用逻辑，同时由 JVM 保证 close 执行，无需在 finally 里再写条件判断。
- 例如打开文件后，先 if 判断内容长度是否符合要求，再决定是否解析；无论是否满足条件，流都会被自动关闭
- 避免在 finally 中重复检查资源是否为 null 再 close——try-with-resources 已隐式处理
