# 1. 异常处理的分层原则中哪一层捕获、哪一层转译、哪一层兜底？"吞异常"和"异常当流程控制"两类反模式的危害？ A 任何异常都在最内层捕获 B 捕获异常后静默即可 C 业务层捕获可恢复、边界层转译、框架层兜底；吞异常应记录/传播，异常当流程控制应改用条件/Result ✓ 正确答案 D 用异常判断正常业务分支
# 2. 统一错误码体系如何设计（业务码/系统码/HTTP 状态码的映射与分段规划），错误码字典如何集中定义、版本化与文档化？ A 错误码散落各处，各自定义 B 前端用 HTTP 状态码做精细分支 C 分段规划业务码/系统码，映射 HTTP 状态码，错误码字典集中定义、版本化并文档化，前端用 code 分支 ✓ 正确答案 D 错误码无需版本化
# 3. "异常即流程控制"的反模式如何识别，如何用 Result/Option 类型重构？ A 用异常处理正常业务状态 B 全部用异常 C 识别"用异常处理正常状态/频繁抛异常"，用 Result/Option 显式表达可预期失败，异常保留给不可预期/类型化错误 ✓ 正确答案 D 全部用 Result，禁用异常
# 4. 异常吞噬(Swallowed Exception)与"记录后继续"的边界在哪里，如何设计合理的降级？ A 吞异常（不记录不处理）是反模式；降级是"非关键失败记录后继续"，需明确降级策略、记录日志、可配置且隔离 ✓ 正确答案 B 吞异常与降级相同 C 所有异常都静默 D 降级无需记录
# 5. 异步代码中的异常传播中 Future/Promise、回调与事件循环下异常如何捕获与传递，未处理拒绝如何治理？ A 异步异常自动到达调用方 B unhandled rejection 可忽略 C 异步异常无需处理 D 异步异常通过 Future/Promise 失败通道、回调 error、事件循环 unhandled 传播；每个异步链要有错误处理，并全局监听 unhandled 上报 ✓ 正确答案
# 6. 全局错误处理在框架层（Spring @ControllerAdvice、React ErrorBoundary）的统一契约？ A Spring @ControllerAdvice 统一后端错误响应，React ErrorBoundary 统一前端错误展示与上报，形成前后端一致错误契约 ✓ 正确答案 B 每个 Controller 各自 try/catch C 错误处理只在业务层 D 前端错误无需处理
# 7. 业务错误码与 HTTP 状态码的边界（4xx/5xx 何时用业务错误码）？ A 只用 HTTP 状态码即可 B HTTP 状态码做粗分类（4xx/5xx），业务码做细粒度业务原因，前端主要依赖业务码分支 ✓ 正确答案 C 只用业务错误码 D 一个业务码对应所有状态码
# 8. 受检异常与非受检异常的取舍争论中现代工程（Java/Kotlin/Go error）实践如何收敛？ A 从受检异常强制转向错误值（Result/error）+ 非受检异常兜底；可预期错误用返回值，不可预期用异常 + 全局兜底 ✓ 正确答案 B 受检异常必须保留 C 全部用受检异常 D 全部用非受检异常
# 9. 防御式编程与契约式设计（前置/后置条件、不变式）的边界中过度防御的代码坏味道？ A 所有方法都防御性校验 B 防御越多越好 C 完全不做防御 D 边界防御外部输入，内部用契约（前置/后置/不变式），过度防御（内部重复校验）是坏味道，掩盖 bug ✓ 正确答案
# 10. 错误码与异常体系如何共存，对外 API 返回码、对内抛异常的分层约定，跨层传播时何时转换、何时透传？ A 对外 API 用返回码，对内用异常；业务异常在边界转错误码，系统异常转 5xx，编程错误透传给兜底 ✓ 正确答案 B 所有层都用异常 C 所有层都用错误码 D 每层都转换异常
# 11. 跨服务调用时如何传递错误上下文（错误码、TraceID、业务单据号）？ A 传递错误码（业务语义）+ TraceID（HTTP 头传播，链路追踪关联）+ 业务单据号，形成可追溯错误链 ✓ 正确答案 B 只传错误码 C 错误不跨服务传播 D TraceID 只在单服务内有效
# 12. 如何设计"可恢复错误"与"不可恢复错误"的分类，并据此决定降级、熔断重试与失败传播的边界？ A 所有错误都重试 B 重试无需幂等 C 所有错误都失败传播 D 可恢复错误（瞬时/超时）用重试+熔断+降级，不可恢复错误（参数/规则）失败传播，错误码标 retryable，重试要幂等 ✓ 正确答案
# 13. 空值语义的编码规范中 null、空集合、空字符串的语义区分，以及空指针安全（Optional、空对象模式）如何作为错误处理规范的一部分？ A null 与空集合等价 B 区分 null（无值）、空集合（无结果）、空字符串（空值），用 Optional/空对象模式/@Nullable 显式化空值，避免 NPE ✓ 正确答案 C 空集合返回 null 即可 D 空值无需规范
# 14. 资源清理阶段的异常安全中 finally/RAII 中清理操作抛异常时如何不掩盖原始异常，如何记录与上报？ A 清理异常覆盖主异常即可 B 清理异常忽略 C 清理异常不掩盖主异常（Java try-with-resources 用 suppressed 合并），清理失败记录日志，两者都上报 ✓ 正确答案 D finally 中清理抛异常会破坏主异常
# 15. 异常消息的上下文规范中 message 应包含哪些操作与实体信息，如何与错误码和参数化模板配合，避免敏感信息？ A message 含操作/实体/参数上下文，用参数化模板 + 错误码分类，对外 message 精简无敏感，内部日志含细节 ✓ 正确答案 B message 包含密码和完整 SQL C message 随便写 D 异常消息不脱敏
# 16. 错误信息本地化与前端可读性的统一规范 A 后端硬编码一种语言 message B 错误码无需本地化 C 前端直接显示堆栈 D 错误码作为稳定 key，前端按语言渲染本地化文案；后端返回错误码+参数，面向用户文案简洁友好、技术细节进日志 ✓ 正确答案
# 17. 异常信息中敏感数据（堆栈、SQL、PII）泄漏的规范约束？ A 对外响应只返回错误码+精简 message，堆栈/SQL 进内部日志，日志 PII 脱敏，防止泄漏 ✓ 正确答案 B 对外响应返回完整堆栈 C 日志记录完整 PII D SQL 可出现在对外 message
# 18. 异常的类型设计中自定义异常与继承体系？ A 每个业务场景一个异常子类 B 设计基类（含错误码/状态/上下文）+ 类别（Business/System/Infrastructure），异常类型按类别分层，细粒度用错误码区分 ✓ 正确答案 C 只用标准异常 D 异常继承体系随意
# 19. 异常的性能成本中热路径中构造异常的代价与替代方案（Result/返回码），何时值得优化？ A 所有失败都用异常 B 异常构造有堆栈成本，热路径可预期错误用 Result/返回码替代，不可预期低频保留异常，以测量为准避免过早优化 ✓ 正确答案 C 所有失败都用 Result D 异常性能无所谓
