应依错误性质选择：可恢复、预期问题用返回值，如查找未命中、API错误码；不可恢复、违契情况用异常，如参数违规、资源不可用；需明确错误边界，避免异常滥用，常混合使用以兼顾健壮与清晰。
Java中该用异常还是返回值，关键看错误性质：可恢复的、预期内的问题用返回值；不可恢复的、意外的、违反契约的情况用异常。
什么情况该用返回值
当方法调用失败是业务常态，且调用方能自然处理时，返回值更轻量、更明确。
- 查找操作未命中（如Map.get(key)返回null或Optional.empty()）
- 解析字符串可能失败（如Integer.parseInt()虽抛异常，但自定义tryParseInt(String)可返回Optional
） - API调用返回标准错误码（如HTTP响应含200 OK或404 Not Found，上层统一解析）
什么情况必须用异常
当方法无法履行其契约，继续执行会导致状态不一致或逻辑错乱时，必须中断流程并抛出异常。
- 参数严重违规（如传入null给不允许为空的参数，抛IllegalArgumentException）
- 资源不可用（如文件不存在、数据库连接中断，抛FileNotFoundException或SQLException）
- 系统级约束被突破（如并发修改冲突、内存溢出，抛ConcurrentModificationException或OutOfMemoryError）
如何设计清晰的错误边界
在模块或接口层面明确“哪些错归我管，哪些错往上推”，避免异常泛滥或静默吞没。
- 底层工具类（如IO、JSON解析）可抛受检异常，让调用方决策；业务服务层尽量转为运行时异常或封装为业务异常（如UserNotFoundException）
- 不要用异常控制正常流程（如用catch(NumberFormatException)做类型判断）
- 返回值方案需配套约定：统一用Result
包装成功/失败，包含code、message、data，比裸null或布尔值更健壮
混合策略的实际应用
真实项目中常组合使用：外层用异常兜底，内层用返回值精细处理。
- 一个支付方法先校验余额（返回Result），再调第三方接口（捕获IOException并转为PaymentNetworkExceptio
n）
- Web层统一拦截业务异常，转为HTTP状态码和JSON错误响应；同时记录日志，但不暴露堆栈给前端
- 命令行工具中，解析参数失败直接打印帮助并退出（返回值控制流），而写配置文件失败则抛异常并提示用户检查权限
