应依问题性质选择：异常用于意外错误，返回值用于可预期业务分支；资源不可用、违反契约、系统故障必须用异常，查找未命中等常见失败宜用返回值。
Java中该用异常还是返回值，关键看问题性质：异常用于处理“意外的、不该发生”的错误；返回值适合“可预期的、业务逻辑中的正常分支”。选错会降低代码可读性，甚至掩盖真正问题。
什么情况必须用异常
当操作失败表示程序处于不合法状态，或调用方无法合理恢复时，必须抛异常：
-
资源不可用：如文件不存在（
FileNotFoundException）、网络连接超时（IOException） -
违反契约：传入非法参数（
IllegalArgumentException）、空指针（NullPointerException） -
系统级故障：内存溢出（
OutOfMemoryError）、类加载失败（NoClassDefFoundError）
什么情况更适合返回值
当失败是业务流程中常见、可预测且调用方能主动应对时，返回值更清晰：
-
查找操作未命中：比如从缓存取用户，没找到返回
null或Optional.empty()，比抛UserNotFoundException更自然 -
解析输入可能失败：如解析日期字符串，用
DateTimeFormatter.parseBest()返回null或封装结果对象，避免把格式错误全变成异常 -
策略选择分支：支付方式不可用时返回
PaymentResult.failure("余额不足")，而非抛InsufficientBalanceException
避免常见误用陷阱
这些做法看似方便，实则破坏错误处理语义：
-
用异常控制流程：比如用
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或抛异常都更安全、明确
