Exception 是程序运行中可预期、可恢复的问题，如文件不存在或网络超时；Error 是 JVM 无法处理的严重故障，如 OutOfMemoryError，不可恢复且不应捕获。
Exception 和 Error 的根本区别在哪
Exception 是程序运行中**可预期、可恢复**的问题，比如文件不存在、网络超时、用户输入非法——你写代码时就能想到“它可能发生”，而且调用方通常能做点什么（重试、提示、降级）。Error 则是 JVM 自身扛不住的严重故障，比如 OutOfMemoryError、StackOverflowError，它们不归业务逻辑管，也几乎无法在应用层 catch 住并“优雅处理”。你 catch 了 OutOfMemoryError，大概率只是延缓崩溃几毫秒，而不是真正解决问题。
为什么 return -1 / null 不该替代异常
错误码本质是把控制流逻辑塞进返回值，结果就是：调用方必须手动检查每一处返回，漏一个就崩；日志里只看到 result = -1，没有堆栈、没有上下文、没有时间戳；多层嵌套后，原始失败原因早被吞掉，最后只剩“功能没反应”这种玄学问题。而异常强制暴露失败——编译器盯住受检异常，IDE 提示未处理，运行时堆栈自动带出完整调用链。
- getUserById(1001) 返回
null，下游直接调user.getName()→NullPointerException - 改成抛
UserNotFoundException，调用方要么 try-catch，要么声明 throws，没法假装看不见 - 错误码相同（都用 -1），但实际可能是参数错、DB 连不上、还是 Redis 超时？异常类型天然区分语义
自定义异常该怎么设计才不踩坑
别只扔个字符串消息。真正的异常要能支撑日志提取、监控告警、前端友好提示三件事。关键点就三个：
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 继承
RuntimeException还是Exception？看调用方是否“合理可恢复”：DB 连接失败（SQLException）是受检异常，用户 ID 不存在（UserNotFoundException）一般用非受检 - 字段比消息重要：把
userId、traceId、HTTP 状态码（如 404）、脱敏后的原始响应体存为 final 字段，别只拼在super("...")里 - 异常链不能断：catch 到底层异常（比如
HttpClientException）后，用new BusinessException(..., e)包一层再抛，保留原始堆栈
错误码（error code）还在用？那得规范起来
错误码不是不能用，而是不能裸用。它必须和异常绑定，作为异常的一个结构化字段，而不是返回值里的 magic number。比如定义统一枚举 ErrorCode.USER_NOT_FOUND，所有 UserNotFoundException 都携带它，并通过全局异常处理器转成 HTTP 响应体中的 {"code": "USER_NOT_FOUND", "message": "...", "traceId": "..."}。这样前后端才能对齐语义，监控系统才能按 code 聚类告警，而不是靠 grep 日志里零散的 “-1” 或 “用户不存在”。
立即学习“Java免费学习笔记（深入）”；
最容易被忽略的是：错误码本身没有上下文价值。同一个 USER_NOT_FOUND，发生在登录流程和导出报表流程，业务含义和恢复方式完全不同——所以异常对象里必须存场景标识（比如 operationType = "login"），而不是指望靠 code 字符串硬编码判断。
