应将可控错误用前置校验或断言替代异常处理，而外部不确定性必须保留try-catch；优化方向包括try-with-resources、多异常捕获、异常上移和自定义封装。

Java中try-catch本身不破坏可读性，真正损害可读性的是滥用、宽泛捕获、空处理或把业务校验逻辑塞进异常流程。断言（assert）不能替代try-catch，二者定位不同：断言用于开发期快速暴露编程错误，而try-catch处理运行时不可控的外部异常（如IO失败、网络超时）。所谓“重构为断言”，实则是识别出本不该走异常路径的逻辑，提前用防御性检查+明确报错取代隐式异常抛出。

哪些try-catch场景其实该用断言或前置校验？

当异常源于开发者可控的输入或状态，且该情况在正确编码下绝不应发生，就属于断言或显式校验的范畴：

• 参数非法但属内部调用失误：比如Service方法接收一个userId，约定非空，却因上游误传null导致NullPointerException。此时应在方法入口用Objects.requireNonNull(userId, "userId must not be null")，而非靠catch NPE——后者掩盖了调用方bug。
• 状态机非法转移：订单状态从“已取消”又调用“发货”，这违反业务规则。应在校验阶段抛出自定义异常（如IllegalStateException），或直接用assert status == ORDER_CREATED : "only created order can be shipped"（仅限开发/测试环境启用）。
• 配置值明显越界：读取线程池大小配置为-5，这不是运行时异常，而是配置错误。应在加载配置后立即校验：if (poolSize 。

什么时候必须保留try-catch，不能“重构”为断言？

以下情况无法用断言替代，必须依赖try-catch机制：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• 受检异常（Checked Exception）强制要求：如FileInputStream构造可能抛FileNotFoundException，JVM编译器强制你捕获或声明。断言对这类外部不确定性无效。
• 资源操作失败不可预测：数据库连接中断、磁盘满、网络抖动——这些是真实环境中的客观风险，不是代码缺陷。必须用try-catch捕获并执行降级、重试或日志记录。
• 需要统一恢复策略：比如所有IO异常都转为用户友好的提示“系统繁忙，请稍后再试”，这种跨模块的语义转换只能在catch块中完成，断言做不到。

提升可读性的重构方向：精简异常路径，分离关注点

与其强行“转成断言”，不如优化异常处理结构本身：

• 用try-with-resources替代手动close：消除finally块和冗余判空，让资源管理逻辑消失于视线之外，主流程更干净。
• 合并同类异常处理：若多个catch块只做同一件事（如都记录日志+返回默认值），可用多异常捕获语法：catch (IOException | SQLException e)。
• 上移异常处理层级：Controller层统一用@ControllerAdvice + @ExceptionHandler捕获业务异常，Service层专注抛出UserNotFoundException等语义化异常，避免每处都写重复的try-catch。
• 用自定义异常封装原始异常：将SQLException包装为OrderPersistenceException，隐藏技术细节，暴露业务含义，调用方只需关心“下单失败”，无需理解JDBC。

断言使用的实际约束

Java断言默认关闭，生产环境几乎不起作用。因此：

• 断言不是错误处理机制：它不保证执行，不能用于释放资源、更新状态或影响程序正常流程。
• 仅用于开发期快速失败：适合验证私有方法的不变量、算法中间状态，例如assert result >= 0 : "sqrt should not return negative"。
• 永远不要用assert替代null检查或参数校验：因为生产环境assert被禁用，会导致NPE等未预期崩溃。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南