受检异常与泛型存在天然张力，因类型擦除导致异常处理与类型安全难以兼顾；泛型方法应统一异常语义、增强错误定位、避免静默吞异常；数组与泛型不兼容，须规避 new T[]；DAO 层应将 SQLException 包装为运行时异常，上层按需用 Optional 处理可恢复场景。
受检异常与泛型的天然张力
受检异常要求编译器强制处理，泛型则在编译期擦除类型信息——二者叠加时容易暴露设计矛盾。典型场景是：一个泛型工具方法（如 <T> T parse(String s)）既要处理外部输入失败（如 JSON 格式错误），又需保证类型安全。若底层用 IOException 或 ParseException 这类受检异常，调用方就得为每个 T 的具体类型重复声明 throws；而若统一转成运行时异常，又可能丢失“可恢复性”的语义提示。
泛型方法中异常签名的设计原则
泛型本身不改变异常规则，但会放大异常意图模糊的问题：
- 不要因类型参数变化随意变更抛出的异常类型。例如 <T> T fromJson(String json) 抛 IOException（IO 失败）和 ClassCastException（类型不匹配）是两类问题，后者说明泛型使用有误，应提前拦截或改用更精准的异常（如 TypeMismatchException）
- 若解析逻辑依赖运行时类型（如 Gson 反序列化），异常信息里必须包含 T.class.getSimpleName()，否则堆栈里只显示 Object，无法定位是 User 还是 Order 出错
- 避免在泛型类内部静默捕获 ClassCastException 并吞掉——这通常意味着调用方传入了错误的类型实参，不是该掩盖，而是该报错
数组与泛型结合时的异常风险
泛型数组创建（如 new List<String>[10]）会触发 ArrayStoreException，根源是类型擦除后 JVM 只看到 List[]，但运行时实际存入的是 ArrayList 或 LinkedList，类型检查失效。这不是受检异常，却是泛型与数组不兼容的典型表现：
- 禁止直接 new T[]；若必须用数组，用 Object[] + 显式转型，并在关键位置加 instanceof 防御（注意：泛型擦除后不能写 item instanceof T，得用 Class<T> 参数辅助判断）
- 优先用 ArrayList<T> 替代数组，它由泛型容器自身保障类型安全，不会在 add 时抛 ArrayStoreException
- 若需返回数组（如 toArray()），用 list.toArray(new T[0]) 形式——这是 Java 容器约定的“安全擦除”写法，由 ArrayList 内部通过反射构造正确类型的数组
调用链中受检异常的泛型适配策略
当泛型 DAO 接口方法抛出 SQLException，而上层 Service 是泛型操作（如 <E> E save(E entity)），不应让所有业务方法都声明 throws SQLException：
立即学习“Java免费学习笔记（深入）”；
- 在 DAO 实现类中，第一时间将 SQLException 包装为自定义的 DataAccessException（继承 RuntimeException），保留 cause，同时隐藏 JDBC 细节
- DAO 接口方法签名不声明受检异常，而是靠文档或注解说明“可能因数据问题失败”，把恢复逻辑（重试、降级、补偿）留给 Service 层统一决策
- 对真正需要调用方干预的场景（如配置加载失败导致功能不可用），用 Optional<T> 返回结果，而非抛受检异常——“找不到配置”是正常分支，不是错误
