Java异常处理与AOP报错拦截技巧

在IT行业这个发展更新速度很快的行业，只有不停止的学习，才不会被行业所淘汰。如果你是文章学习者，那么本文《Java异常处理与AOP报错拦截详解》就很适合你！本篇内容主要包括##content_title##，希望对大家的知识积累有所帮助，助力实战开发！

@AfterThrowing仅捕获方法正常执行后抛出的异常，若异常被try-catch吞没、发生在代理边界外（如线程池）、或目标方法非Spring Bean，则无法触发；需配合@Around实现异常兜底。

Java异常没被catch住，为什么AOP还是捕获不到？

因为 @AfterThrowing 切面只对「方法正常执行完但抛出异常」的场景生效，如果目标方法里自己 try-catch 了异常又没重新抛出，或者异常在 Spring 代理边界外（比如线程池、异步回调、静态方法）发生，AOP 就完全看不见。

常见错误现象：@AfterThrowing 一个日志都没打，但控制台明明有 NullPointerException 堆栈；或者只在 Controller 层生效，Service 里空指针却没触发切面。

• 确保目标方法是 Spring 管理的 Bean（不能 new 出来，也不能是 private/static）
• 检查是否开启了 AspectJ 代理模式：@EnableAspectJAutoProxy(proxyTargetClass = true) 更稳妥，尤其对接口多实现类的场景
• 若用 @Async 或 CompletableFuture，异常默认不传播到主线程，需显式处理或改用 @Async 的异常处理器

用 @AfterThrowing 拦截异常时，怎么拿到原始异常和参数？

靠切点表达式 + 方法签名匹配。Spring AOP 不支持直接获取被拦截方法的局部变量，但可以拿到入参、返回值（@AfterReturning）、异常对象（@AfterThrowing）和方法元信息。

使用场景：统一记录报错参数、脱敏手机号、标记重试标识、转发告警。

@AfterThrowing(pointcut = "execution(* com.example.service..*.*(..))", throwing = "ex")
public void logException(JoinPoint joinPoint, Throwable ex) {
    Object[] args = joinPoint.getArgs();
    String methodName = joinPoint.getSignature().getName();
    log.error("method={} args={} error={}", methodName, Arrays.toString(args), ex.getMessage());
}

• throwing = "ex" 中的字符串必须和方法参数名严格一致
• JoinPoint.getArgs() 返回的是原始引用，修改它不影响原方法逻辑（但别真去改，语义混乱）
• 如果只想拦截特定异常，切点里加 throws NullPointerException 不起作用，得在方法体内 if (ex instanceof XxxException) 判断

Controller 层全局异常处理（@ControllerAdvice）和 AOP 切面冲突吗？

不冲突，但职责不同、触发时机不同。AOP 在方法执行后感知异常（属于「业务流程钩子」），而 @ControllerAdvice 是 Spring MVC 的异常翻译机制，在 DispatcherServlet 处理完 Controller 后才介入，且只对 Web 层有效。

性能影响：两者都轻量，但 @ControllerAdvice 会中断请求流程并渲染响应体，AOP 则纯属旁路记录/增强，不影响返回值。

• 想统一返回 JSON 错误结构 → 用 @ControllerAdvice + @ExceptionHandler
• 想审计所有 service 方法的失败率、慢调用、入参特征 → 用 AOP
• 不要在 @ControllerAdvice 里再 throw 新异常试图触发 AOP —— 此时方法早已执行完毕，AOP 不会二次响应

为什么切面里 try-catch 了异常，业务代码还是报错？

因为 @AfterThrowing 是「通知」，不是「拦截器」。它像站在门口看人摔跤，但不扶；你可以在里面记日志、发消息，但无法阻止异常向上冒泡。

真正能吞掉异常的只有 @Around，它把目标方法包在自己里面，有完全控制权。

@Around("execution(* com.example.service..*.*(..))")
public Object handleException(ProceedingJoinPoint joinPoint) throws Throwable {
    try {
        return joinPoint.proceed();
    } catch (BusinessException e) {
        log.warn("business error ignored: {}", e.getMessage());
        return Result.fail(e.getCode(), "操作失败");
    }
}

• @Around 必须显式调用 proceed()，否则目标方法根本不会执行
• 若 proceed() 抛出异常，你 catch 之后可以选择返回默认值、包装新异常、或重新 throw
• 过度使用 @Around 容易掩盖真实问题，建议只在明确需要「兜底返回」的场景用（如降级、缓存穿透防护）

最容易被忽略的一点：AOP 和异常处理不是替代关系，而是分层协作。底层 Service 抛具体异常，中间 AOP 做可观测性增强，上层 Web 层做用户友好的错误呈现 —— 三层各干各的，混在一起反而难定位。

今天关于《Java异常处理与AOP报错拦截技巧》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！