java中try-catch不能保证程序不崩溃，但能防止未处理异常导致线程终止或jvm退出；关键在于捕获合适异常、做有意义处理、不掩盖问题、不忽略错误。
Java 中 try-catch 本身不能“保证程序不崩溃”，但它能防止 未处理的异常导致线程终止或 JVM 退出。真正关键的是：捕获合适的异常、做有意义的处理、不掩盖问题、不忽略错误。下面从实用角度说明怎么写才更健壮。
只捕获你有能力处理的异常类型
不要用 catch (Exception e) 或 catch (Throwable t) 捕获一切。这容易吞掉本该暴露的严重问题（比如 OutOfMemoryError、NullPointerException 本意是代码缺陷，不是运行时可恢复的“意外”）。
- 优先捕获具体受检异常（如
IOException、SQLException），它们代表外部依赖可能失败，你通常可以重试、降级或提示用户 - 对运行时异常（如
IllegalArgumentException），除非你明确知道为何发生且能安全绕过（例如解析用户输入失败时返回默认值），否则不应盲目 catch - 绝对避免捕获
Error及其子类（如StackOverflowError），这类错误表明 JVM 状态已不可靠
catch 后必须有实质处理，不能空着或只打日志
空 catch 块是崩溃隐患的最大帮凶——它让错误静默消失，后续逻辑基于错误状态继续执行，往往引发更隐蔽的失败。
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 记录日志时，要包含异常堆栈（
logger.error("读取配置失败", e)），不能只记一句“出错了” - 根据场景选择：返回默认值、切换备用路径、向用户友好提示、主动抛出封装后的新异常（如
throw new ServiceException("支付调用超时", e)） - 如果当前方法无法处理，就不要 catch，让异常向上冒泡，由更上层统一处理（比如 Spring 的 @ControllerAdvice）
善用 try-with-resources 和 finally 做资源清理
资源泄漏（如文件句柄、数据库连接没关闭）虽不立即崩溃，但会逐渐耗尽系统资源，最终触发 IOException 或 OutOfMemoryError。
- 所有实现
AutoCloseable的资源（FileInputStream、Connection、PreparedStatement），一律用 try-with-resources - 不要在 catch 里关资源——如果 try 块中已抛异常，资源可能根本没成功打开；也不要在 finally 里无条件 close（需判 null，或依赖 try-with-resources）
- finally 适合放不影响主流程的清理动作（如解锁、重置标志位），但别在里面 throw 异常，否则会覆盖原异常
避免在构造函数、静态初始化块、main 方法外随意吞异常
这些地方异常处理不当，极易导致类加载失败、单例创建中断、主线程静默退出。
- 构造函数中若必须处理异常，考虑用工厂方法封装，把异常转为返回 null 或 Optional.empty()
- 静态块里抛异常会导致整个类不可用，应确保初始化逻辑足够稳定，或用双重检查 + volatile 缓存结果
- main 方法中建议包一层 try-catch，至少打印完整异常并调用
System.exit(1)，避免进程假死
不复杂但容易忽略：try-catch 是防御手段，不是补丁。真正的稳定性来自清晰的错误边界、合理的异常分类、以及每个 catch 块背后明确的业务意图。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
