Java异常应谨慎暴露给用户

Java应用中异常信息绝不能直接暴露给用户，否则将引发严重安全风险——如泄露数据库路径、中间件版本、敏感字段名等攻击线索；必须通过统一异常拦截机制，将所有异常转换为无技术细节的业务错误码与模糊提示，同时在日志中完整、脱敏地记录原始堆栈以保障可追溯性，尤其对第三方SDK异常需显式捕获、安全包装并保留cause链，确保用户体验与系统安全兼得。

用户看到的异常信息必须过滤和重写

Java 应用直接把 Exception.toString() 或堆栈打印（e.printStackTrace()）返回给前端或界面，属于典型的安全漏洞。真实错误如数据库连接失败、文件路径不存在、SQL 语法错误，往往包含环境细节（/app/config/db.properties）、中间件版本（HikariCP-5.0.1）、甚至用户名字段名（user_pwd），这些都可能被用于进一步攻击。

正确做法是：所有抛到外层的异常必须经过统一拦截，转换为预定义的业务错误码 + 模糊化提示。例如：

try {
    userService.updateProfile(user);
} catch (SQLException e) {
    throw new BusinessException("E002", "用户信息保存失败，请稍后重试");
}

• 不暴露具体技术栈（避免说“MySQL 连接超时”）
• 不暴露路径、类名、方法名（禁止出现 com.example.dao.UserDao.save()）
• 错误码 E002 仅用于日志追踪，前端不可解析含义

日志中必须保留原始异常完整堆栈

用户看不到的错误详情，要确保能被运维和开发快速定位。关键不是“记不记”，而是“怎么记”。常见错误是只记录 e.getMessage()，导致丢失根因。

使用 SLF4J / Log4j 时，必须传入 Throwable 参数：

logger.error("Failed to process payment for order {}", orderId, e);

• 上面这行会输出完整堆栈；而 logger.error("...{}", e)（把异常当参数）只会打印 toString()，丢掉堆栈
• 敏感字段（如密码、token）需在日志脱敏：用 LogMasker 工具类或 AOP 拦截器提前清理 e.getStackTrace() 中的敏感上下文
• 异步线程中抛出的异常容易丢失，务必用 Thread.setDefaultUncaughtExceptionHandler 补漏

Spring Boot 的 @ControllerAdvice 处理边界要清晰

很多人以为加个 @ControllerAdvice 就万事大吉，但实际容易混淆三类异常的处理优先级：

• BusinessException（自定义业务异常）→ 返回 400 + 标准 JSON 错误体
• IllegalArgumentException 等运行时异常 → 视为客户端输入错误，也走 400，但不记录 ERROR 级别日志
• NullPointerException、SQLException 等系统异常 → 返回 500，强制记录 ERROR 日志，并触发告警

特别注意：@ResponseStatus 注解不能替代逻辑判断——它只改 HTTP 状态码，不控制响应体内容。真正要区分响应格式，得靠 @ExceptionHandler 方法里手动构造 ResponseEntity。

第三方 SDK 抛出的异常更要小心包装

调用微信支付 SDK 抛出的 WeChatPayException、调用阿里云 OSS 的 OSSException，这类异常自带详细报错字段（如 err_code: INVALID_REQUEST、request_id: xyz123），直接透出等于交出调试权限。

必须做两件事：

• 用 instanceof 显式捕获，不依赖通用 Exception 捕获（否则可能吞掉本该 500 的严重错误）
• 提取其中可安全暴露的字段（比如微信的 return_msg 是面向商户的，可转成用户提示；但 err_code_des 含调试细节，必须丢弃）
• 保留原始异常作为 cause，供日志链路追踪：用 new BusinessException("E007", "支付请求未完成", wechatEx)

最常被忽略的一点：SDK 异常可能带二进制响应体（如图片上传失败时返回的错误 HTML），不清理就序列化进日志，会导致 ELK 解析失败或磁盘暴涨。

本篇关于《Java异常应谨慎暴露给用户》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！