不应捕获 AssertionError，因其属 Error 类型，标志程序逻辑错误而非可恢复异常；应改用 IllegalArgumentException 等明确异常做业务校验，并通过 -ea 启用断言辅助调试。
不能捕获 AssertionError，也不应该尝试捕获它。
断言不是普通异常，而是程序逻辑错误信号
assert 的设计目的不是处理运行时可恢复的错误，而是帮助开发者在开发/测试阶段快速发现违反前提条件的 bug。当断言语句失败时，JVM 抛出 AssertionError（继承自 Error，而非 Exception），这表示程序已处于不一致或不可预期的状态。
-
Error类型（如OutOfMemoryError、StackOverflowError）通常不建议捕获，因为它们反映的是严重问题，程序难以安全继续执行 - 捕获
AssertionError容易掩盖真正的逻辑缺陷，让问题潜伏到生产环境 - 断言默认是关闭的（需用
-eaJVM 参数启用），生产环境一般禁用，捕获逻辑会变成“死代码”
正确做法：用异常替代断言做业务校验
如果需要在运行时检查条件并响应错误，应使用明确的异常抛出，而不是依赖断言：
- 参数校验用
IllegalArgumentException - 状态非法用
IllegalStateException - 外部约束失败（如文件不存在）用对应受检或非受检异常
例如：
立即学习“Java免费学习笔记（深入）”；
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
throw new IllegalArgumentException("value must not be null");
}
这样既能清晰表达意图，又便于上层 try-catch 处理或统一异常拦截。
调试时启用断言，而非捕获它
开发中可通过以下方式让断言生效并观察失败位置：
- 运行时加参数：
java -ea MyApplication（-ea启用所有断言） - IDE 中配置 VM options（如 IntelliJ：Run → Edit Configurations → VM options 输入
-ea） - 断言失败时，堆栈会直接指向出问题的
assert行，方便定位逻辑漏洞
极少数例外：测试框架中可能“捕获”断言失败
单元测试（如 JUnit）内部会拦截 AssertionError 并将其转化为测试失败结果，但这属于框架行为，不是业务代码主动 catch。你自己写代码时不应模仿这种模式。
例如 JUnit 5 的 assertThrows() 是专门用于验证某段代码是否抛出指定异常，但它底层不靠 catch(AssertionError)，而是通过执行上下文隔离和异常传播机制实现。
