应使用uncaughtexceptionhandler统一捕获未处理异常，而非重定向system.err；因其可兜底线程级异常，而system.err仅捕获显式printstacktrace()输出，无法发现静默吞没的异步异常。
不能直接“重写”System类的控制台输出流来捕获“被动吞没的任务异常”。这个目标存在概念混淆：输出流（如System.out、System.err）只负责打印文本，不参与异常抛出、捕获或任务执行逻辑；而“被动吞没的异常”通常指未显式处理、被静默忽略的异常（例如在Future.get()未调用、CompletableFuture未exceptionally()、或线程中未捕获的Throwable），它们根本不会经过System.err，除非代码主动调用了e.printStackTrace()。
明确问题根源：吞没异常 ≠ 输出到控制台
真正需要解决的是：**如何可靠地发现并捕获那些本该暴露却悄然消失的异常**。常见场景包括：
-
ExecutorService提交的Runnable中抛出未捕获异常（线程终止，无日志） -
CompletableFuture链中使用thenApply等非异常处理方法时上游失败被忽略 -
ForkJoinPool中任务异常未传播，仅静默失败 - 第三方库异步回调未声明异常，导致
RuntimeException被吞没
推荐方案：用UncaughtExceptionHandler统一兜底
这是最有效、侵入性最小的方式——它能捕获所有未被业务代码处理的线程级异常：
- 为自定义线程池设置
ThreadFactory，在创建线程时指定UncaughtExceptionHandler - 对
main线程也可通过Thread.currentThread().setUncaughtExceptionHandler(...)设置 - 处理器中可记录日志、上报监控、甚至触发告警，而非依赖
System.err
示例：
ExecutorService exec = Executors.newCachedThreadPool(r -> {Thread t = new Thread(r);
t.setUncaughtExceptionHandler((thread, ex) -> {
log.error("Uncaught exception in thread {}", thread.getName(), ex);
});
return t;
});
补充手段：增强异步任务的异常可见性
在代码层面主动预防吞没，比事后捕获更可靠：
-
CompletableFuture链中，每个关键步骤后追加exceptionally()或handle()，确保失败路径有响应 - 使用
submit(Callable)代替submit(Runnable)，让Future.get()强制暴露检查异常和运行时异常 - 对
Runnable包装一层通用异常捕获模板：
public static Runnable safe(Runnable r) {
return () -> {
try { r.run(); }
catch (Throwable t) { log.error("Task failed", t); throw t; }
};
}
不推荐的做法：重定向System.err
即使将System.setErr()指向自定义PrintStream，也仅能捕获显式调用printStackTrace()的异常堆栈，对绝大多数静默失败的任务毫无作用。它还可能干扰正常诊断日志、掩盖真实问题位置，且无法区分业务异常与系统异常。
