Java中try-catch失效主因有三：一是catch(Exception)漏掉Error和部分异常，应按需捕获具体类型或谨慎用catch(Throwable)；二是异常发生在异步线程等try作用域外，需在run()或CompletableFuture中处理；三是异常被静默吞掉、未记录日志或未保留cause链。
Java里写了try-catch却还是报错退出，不是代码没写对，而是捕获逻辑本身有盲区。关键得看清：你catch的是谁、异常从哪来、有没有被绕过去。
catch(Exception e) 本身就漏掉一大类
Exception 类不包含 Error（如 OutOfMemoryError、StackOverflowError）和部分特殊异常（如 InvocationTargetException）。这些异常即使抛出来，用 catch(Exception) 也完全接不住。
- 想兜底所有可拦截的异常，得用 catch(Throwable t) —— 但要谨慎，Error 一般不该也不该被业务代码“吞掉”
- 日常建议：按需捕获具体类型（比如 IOException、SQLException），比笼统 catch(Exception) 更安全、更易定位问题
- 如果真要统一兜底（如全局异常处理器），用 Throwable + 排除已知严重错误（比如判断 t instanceof Error 再跳过处理）
异常根本没进你的 try 块
常见于异步场景：线程、回调、Lambda、第三方库内部执行的代码。try-catch 写在主线程，异常却发生在子线程里，自然捕获不到。
- Runnable 或 Thread 中的异常，必须把 try-catch 写在 run() 方法内部
- 使用 CompletableFuture 时，异常会封装在 CompletionStage 中，要用 exceptionally() 或 handle() 捕获
- 全局未捕获异常可设置：Thread.setDefaultUncaughtExceptionHandler，适合监控和日志，但不能“恢复”执行
异常被中途“吃掉”或掩盖了
空 catch 块、只打印 stackTrace 却没记录日志、或者上层又 throw 了新异常，都会让原始异常线索消失。
立即学习“Java免费学习笔记（深入）”；
- 避免 catch(Exception e) { } 这种静默吞异常写法
- 记录异常推荐用 e.printStackTrace() 仅用于调试；生产环境务必用日志框架（如 Slf4j）+ e 全参输出
- 若需包装异常再抛出，用 throw new BusinessException("xxx", e) 保留 cause 链，方便追溯根因
检查性异常没声明也没处理
像 IOException、SQLException 这类编译期强制检查的异常，如果方法里抛出了，又没用 try-catch 包住，也没在方法签名加 throws，编译就过不去——但一旦过了编译，运行时反而不会“突然捕获失败”，更多是直接中断。
- 确认 IDE 或编译器是否开启严格检查；Maven 编译失败说明是这里卡住了
- 若不想在当前方法处理，就老老实实用 throws IOException 向上传递
- 别为了过编译而强行 try-catch 后 return null 或默认值，容易掩盖真实问题
基本上就这些。捕获不到异常，八成不是语法错了，而是没对上号、没守好位置、或者压根没让它流到你手里。
