17370845950

应依问题性质选择：异常用于意外错误，返回值用于可预期业务分支；资源不可用、违反契约、系统故障必须用异常，查找未命中等常见失败宜用返回值。

Java中该用异常还是返回值，关键看问题性质：异常用于处理“意外的、不该发生”的错误；返回值适合“可预期的、业务逻辑中的正常分支”。选错会降低代码可读性，甚至掩盖真正问题。

什么情况必须用异常

当操作失败表示程序处于不合法状态，或调用方无法合理恢复时，必须抛异常：

• 资源不可用：如文件不存在（FileNotFoundException）、网络连接超时（IOException）
• 违反契约：传入非法参数（IllegalArgumentException）、空指针（NullPointerException）
• 系统级故障：内存溢出（OutOfMemoryError）、类加载失败（NoClassDefFoundError）

什么情况更适合返回值

当失败是业务流程中常见、可预测且调用方能主动应对时，返回值更清晰：

• 查找操作未命中：比如从缓存取用户，没找到返回null或Optional.empty()，比抛UserNotFoundException更自然
• 解析输入可能失败：如解析日期字符串，用DateTimeFormatter.parseBest()返回null或封装结果对象，避免把格式错误全变成异常
• 策略选择分支：支付方式不可用时返回PaymentResult.failure("余额不足")，而非抛InsufficientBalanceException

避免常见误用陷阱

这些做法看似方便，实则破坏错误处理语义：

立即学习“Java免费学习笔记（深入）”；

• 用异常控制流程：比如用try-catch代替if (map.containsKey(key))——性能差，且混淆错误与逻辑
• 吞掉异常只返回默认值：捕获IOException后静默返回-1，调用方完全不知底层失败
• 自定义异常但不提供上下文：只抛ValidationException却不带字段名和错误值，排查困难
• 过度使用检查型异常：强制调用方写一堆catch，却对大多数场景毫无意义（如SQLException在DAO层已封装为运行时异常更合理）

实用建议：结合使用的平衡方案

真实项目中不必非此即彼，可以分层协作：

• 底层模块暴露异常：IO、数据库、HTTP客户端等直接抛有意义的运行时异常（如HttpClientException）
• 业务层做语义转换：将技术异常转为业务结果，如OrderService.placeOrder()返回Result
• API层统一响应：Spring MVC用@ExceptionHandler把各类异常转为标准JSON错误体，对前端屏蔽实现细节
• 工具方法优先返回Optional：如findUserById(id)返回Optional，比返回null或抛异常都更安全、明确