exception是程序应处理的异常（如ioexception），error是jvm级严重问题（如outofmemoryerror）不应捕获；runtimeexception子类为unchecked异常，需逻辑规避；checked异常必须显式处理。
Java里Exception和Error到底怎么分？
不是所有“出错了”都该捕获——Exception是程序能（且应该）处理的异常，比如IOException、SQLException；而Error（如OutOfMemoryError、StackOverflowError）代表JVM级严重问题，一般不捕获、不重试、不掩盖。
常见误操作：用catch (Exception e)兜底所有异常，结果把本该崩溃的NullPointerException吞掉，掩盖了空指针源头；或试图捕获NoClassDefFoundError并“恢复”，实际类加载失败已不可逆。
-
RuntimeException及其子类（如IllegalArgumentException、ConcurrentModificationException）属于unchecked异常，编译器不强制处理，但应通过逻辑校验提前规避，而非依赖try-catch - 必须显式声明或捕获的是checked异常（即
Exception直接子类，但非RuntimeException），比如FileNotFoundException调用new FileInputStream(path)时必须处理 - 自定义异常建议继承
RuntimeException（业务异常）或Exception（需强制调用方关注的外部异常，如支付网关超时）
Apache Commons Lang的ExceptionUtils怎么用才不踩坑？
它最常被用来获取异常完整堆栈、查找特定类型异常、判断是否嵌套等，但默认行为容易误导：
-
ExceptionUtils.getStackTrace(e)返回字符串，含换行符，日志中直接打印可能破坏结构化日志格式，建议用log.error("msg", e)代替手动拼接 -
ExceptionUtils.indexOfType(e, SQLException.class)只查直接类型，不递归Cause链；要查整个异常链是否含某类，得用ExceptionUtils.containsType(e, SQLException.class) - 注意
getCause()可能为null，而ExceptionUtils.getRootCause(e)会安全遍历到最内层非null cause，但若中间有循环引用（极少见），会抛IllegalStateException
ExceptionUtils.getRootCause(new SQLException("outer", new RuntimeException("inner")))
返回的是RuntimeException("inner")，不是SQLException本身。
基于Intranet/Internet 的Web下的办公自动化系统，采用了当今最先进的PHP技术，是综合大量用户的需求,经过充分的用户论证的基础上开发出来的，独特的即时信息、短信、电子邮件系统、完善的工作流、数据库安全备份等功能使得信息在企业内部传递效率极大提高，信息传递过程中耗费降到最低。办公人员得以从繁杂的日常办公事务处理中解放出来，参与更多的富于思考性和创造性的工作。系统力求突出体系结构简明
立即学习“Java免费学习笔记（深入）”；
Spring的@ExceptionHandler为什么有时不生效？
它只对当前Controller内抛出的异常生效，且受异常传播路径限制：
- 异步方法（
@Async）中抛出的异常不会到达Controller的@ExceptionHandler，因为执行线程已切换，需单独配置AsyncUncaughtExceptionHandler - 过滤器（Filter）或拦截器（Interceptor）中抛出的异常，绕过Spring MVC异常解析流程，
@ExceptionHandler捕获不到，应改用@ControllerAdvice配合@ExceptionHandler全局处理，或在Filter中自行try-catch - 如果异常被更上层AOP切面（如事务管理器）提前捕获并转为其他异常（如
TransactionSystemException），原异常类型丢失，@ExceptionHandler按原类型写的就不会匹配
Logback/SLF4J记录异常时，logger.error("msg", e)和logger.error("msg: " + e)区别很大
前者把Exception对象作为独立参数传入，日志框架能自动提取堆栈并结构化输出；后者只是字符串拼接，堆栈信息完全丢失，只剩e.toString()（通常是类名+message）。
- 拼接方式还可能触发不必要的
toString()或getMessage()调用，在异常未初始化好时导致NullPointerException - 使用占位符（
logger.error("Failed to process {}", id, e)）是安全的：只有当日志级别允许输出时，才会计算参数，避免无谓的对象创建或toString开销 - 敏感信息（如密码、token）不要出现在
getMessage()里，因为堆栈日志默认包含它；应把敏感数据存入异常的suppressed或自定义字段，再通过MDC或自定义ThrowableProxy过滤
异常链越深，越要确认每一层是否真的需要包装——过度嵌套会让根因难定位，而完全不包装又丢失上下文。平衡点通常在：底层IO/DB异常保留原始类型，业务层用自定义BusinessException封装，并通过initCause()关联原始异常。
