java中没有“exception barrier”标准概念，它实为开发者在rpc入口、消息监听器等关键位置手动添加的throwable捕获与统一处理逻辑，需配合堆栈保留、异步异常显式处理及中间件特性适配。
Java里根本没有叫“Exception Barrier”的标准概念
这是个容易让人踩坑的术语混淆点。Java语言规范、JVM规范和主流中间件（如Spring、Netty、Dubbo）源码中，Exception Barrier 并不是一个官方定义的机制或类名。它常出现在某些中文技术文章或内部分享里，实际指代的是「在特定代码边界处集中拦截、转换或终止异常传播」的设计意图——比如过滤器链末尾、RPC调用出口、消息监听器包装层等位置的手动兜底逻辑。
为什么有人会提“Exception Barrier”：典型中间件场景
真正被称作“屏障”的，是开发者在关键路径上主动插入的异常拦截点，目的不是屏蔽异常，而是防止未处理异常穿透到不该去的地方（比如让一个HTTP请求因数据库连接超时直接500，而不做降级或日志补全）。
-
RPC服务端入口：Dubbo的
Filter链末尾或Spring Cloud Gateway的全局GlobalFilter中捕获Throwable，统一转成Result对象返回 -
消息消费线程：Kafka Listener或RocketMQ
MessageListenerConcurrently里用try-catch包住业务逻辑，避免线程因异常退出导致消息重复投递失控 -
定时任务执行器：Quartz的
Job实现中不抛出检查异常，否则调度器可能静默停止该Job
怎么做才真正起作用：别只靠try-catch
光写一层try-catch(Exception e)远远不够，“屏障”要生效，得配合上下文控制和副作用管理。
- 必须捕获
Throwable，而非仅Exception——否则OutOfMemoryError这类错误照样穿透 - 记录日志时一定要保留原始堆栈：
log.error("barrier caught", e)，而不是log.error("barrier caught: " + e.getMessage()) - 如果在异步线程中（如CompletableFuture回调），需显式调用
exceptionally()或handle()，否则异常会被吞掉 - Spring AOP的
@Around切面不能拦截构造器异常或静态初始化块异常，这类地方得靠JVM agent或启动时预检
容易被忽略的兼容性陷阱
不同中间件对异常的默认处理策略差异极大，强行套用同一套“屏障”逻辑反而引发新问题。
立即学习“Java免费学习笔记（深入）”；
- Spring WebMvc中，
@ControllerAdvice能捕获控制器抛出的异常，但对@Bean初始化失败（如DataSource创建异常）完全无效 - Netty的
ChannelHandler里若在exceptionCaught()中没调用ctx.close()或ctx.fireExceptionCaught()，可能导致连接泄漏 - 某些老版本Dubbo（2.6.x）会在异常信息里序列化
toString()结果，如果自定义异常重写了该方法且含敏感字段，会意外泄露
真正的难点从来不在“加一层catch”，而在于判断这个“屏障”该放在哪一层调用栈、是否影响重试语义、会不会掩盖本该暴露的系统级故障信号。
