java中不存在“异常屏障”这一标准概念，它只是对异常传播边界或拦截点的误称；实际机制依赖try-catch、@exceptionhandler、error-page等人工控制点。
Java里根本没有“异常屏障（Exception Barrier）”这个标准概念
这是个常见误解，源于对JVM异常处理机制、框架封装或文档翻译的混淆。Java语言规范和JVM规范中从未定义 Exception Barrier 这一术语。你看到的可能是某框架（如Spring AOP、Resilience4j）对异常拦截逻辑的自定义命名，或是某些中文技术文章对“异常边界”“异常过滤器”的误译。
实际想表达的通常是“异常传播边界”或“异常拦截点”
这类场景真正关心的是：异常在调用链中何时停止向上抛、谁负责捕获、是否被转换或吞掉。典型位置包括：
-
try-catch块 —— 最直接的手动边界，但只作用于当前方法内 - Spring的
@ControllerAdvice+@ExceptionHandler—— Web层全局异常拦截点，能统一处理RuntimeException或特定业务异常 - Servlet容器的
web.xml中<error-page></error-page>配置 —— 容器级兜底，仅对HTTP状态码或Throwable类型生效，不介入Java异常对象本身 - 线程池的
ThreadFactory或UncaughtExceptionHandler—— 捕获未处理的RuntimeException，但无法拦截已声明的CheckedException
为什么容易误以为存在“异常屏障”机制？
几个典型误导来源：
- 某些AOP库（如AspectJ）在切入点周围插入
aroundadvice，看起来像“挡住了异常”，实则是手动try-catch+ 重新抛出/包装，不是JVM层面的屏障 - JVM的
StackFrame本身有异常表（exception_table），但它只用于定位catch块，不提供“过滤”能力；一旦找不到匹配的catch，异常立刻向上传播 - IDE或监控工具（如Arthas）显示“异常在某类某行被捕获”，让人误以为该处是系统定义的“屏障”，其实只是代码写在那里而已
- 部分国产中间件文档把“异常降级开关”叫成“异常屏障”，属于内部术语，不可迁移至通用Java开发
真正需要关注的其实是异常生命周期控制点
如果你的目标是“让异常不穿透到上层服务”，重点不在找一个不存在的屏障，而在明确控制传播路径：
立即学习“Java免费学习笔记（深入）”；
- 避免在
finally块中抛异常 —— 它会覆盖原始异常，导致根因丢失，这是最常踩的坑 - 使用
Optional或Result类型替代部分throw，尤其在非错误场景（如查询无结果）下，减少异常滥用 - 区分
RuntimeException和CheckedException：前者由调用方决定是否处理，后者强制编译期检查，但JVM运行时并无区别 - 注意
CompletableFuture的异常处理：thenApply不捕获异常，必须用exceptionally或handle，否则异常会静默丢失
异常不会自动停在某一层，它只会沿着调用栈往上走，直到遇到第一个匹配的 catch，或者走到线程起点后终止程序。所谓“屏障”，不过是人写的那几行 try-catch 而已。
