标准答案
- 异常类型应表达可处理的失败类别，不能用一个通用 Exception 隐藏所有原因。
- 跨层传播时保留根因和上下文，向外部响应映射为安全且稳定的错误信息。
- 恢复动作要靠幂等、重试和补偿，不能因为 catch 住异常就认为业务成功。
- 日志记录要避免重复打印和敏感数据泄露。
题目解析
checked 与 unchecked 的选择主要表达恢复责任，不是运行时性能差异。调用方确实能够采取替代路径时，可以用明确的 checked 或稳定错误类型；编程错误和当前层无法恢复的失败通常使用 unchecked。
异常跨层传播时要保留 cause、业务上下文和可观测关联，边界层再映射成安全的错误码。catch 住异常不等于业务成功，恢复还要靠幂等、重试和补偿。
异常类型不要被无限细分，也不要用通用 Exception 隐藏所有原因。接口应让调用方知道哪些错误可重试、哪些需要修正请求、哪些需要人工处理。
常见误区
- 误区：catch(Exception) 后返回 null。改正：区分可恢复、不可恢复和业务空值，保留错误证据并明确返回语义。
- 误区：丢失 cause 后重新抛出新异常。改正：使用带 cause 的异常链，保留根因和请求上下文。
- 误区：把异常消息原样返回用户。改正：对外返回稳定错误码和安全提示，详细堆栈只进入受控日志。