异常语义丢失是指nullpointerexception等技术异常缺乏业务上下文，导致无法判断null成因（如未登录、参数缺失或下游返回空），调试困难；应捕获后封装为带业务含义且保留原始异常的业务异常类，并配合前置校验预防。

什么是异常语义丢失

当底层抛出 NullPointerException 时，调用栈往往只显示“对象为 null”，但业务方完全不清楚这个 null 具体代表什么——是用户没登录？订单 ID 未传入？还是库存服务返回了空响应？这类异常缺乏上下文，调试成本高，日志难排查，前端也难以给出友好提示。这就是典型的“语义丢失”：技术异常掩盖了业务意图。

用业务异常包装 NullPointerException

不直接 throw new NullPointerException()，也不让它穿透到上层，而是捕获后封装成带业务含义的异常。关键在于：保留原始异常（便于追踪根因），同时注入可读性强的业务描述。

• 定义清晰的业务异常类，如 MissingOrderParameterException、UserNotLoggedInException
• 在空值检查点主动判断并抛出，例如：if (order == null) throw new MissingOrderParameterException("订单信息未提供，请检查 order_id 参数")
• 若空值来自下游调用（如 feign 调用返回 null），应在服务适配层拦截，补充上下文再抛出，而非让 NPE 向上传播

保持异常链路完整

包装时务必使用带 cause 的构造函数，确保原始堆栈不丢失。这样既能让运维看到真实出错位置，又让业务方一眼理解问题归属。

• ✅ 正确：throw new InventoryNotAvailableException("库存查询结果为空，可能商品已下架", e)
• ❌ 错误：throw new InventoryNotAvailableException("库存不可用")（丢失 e，无法定位是哪行代码触发了 NPE）
• 日志打印时使用 logger.error(msg, e)，而非只打 message，否则堆栈被截断

配合参数校验与防御式编程

异常包装是补救手段，更优解是在入口处就预防 NPE。结合 JSR-303 注解、Optional、非空断言等，把“可能为空”的判断前移到 API 层或 DTO 绑定阶段。

• Controller 方法参数加 @NotNull，配合全局异常处理器统一转为 400 + 业务提示
• Service 内部对关键入参做显式判空，例如：Objects.requireNonNull(userId, "用户ID不能为空")
• 对远程调用结果用 Optional 封装，避免裸 null 流入业务逻辑