Effective Java 异常与泛型核心原则是清晰性与安全性：异常按可恢复性选受检或非受检，避免无意义包装；泛型仅编译期有效，不可绕过擦除，通配符须精准。
Effective Java 中关于异常与泛型的核心原则，不是堆砌语法技巧，而是围绕“清晰性”和“安全性”做取舍：异常要真实反映问题本质，泛型要真正提供类型安全而非徒增复杂。
异常：优先使用受检异常表达可恢复的外部失败
当调用方有合理机会处理并继续执行时（如文件不存在、网络暂时不可达），用受检异常（Exception 的子类）强制调用方考虑；否则用非受检异常（RuntimeException 及其子类）表示编程错误或不可恢复状态（如空指针、非法参数）。不要为“省事”把所有异常都转成 RuntimeException，也不要滥用受检异常迫使调用方写一堆无意义的 try-catch。
- 避免在已有异常语义明确时包装新异常——除非你添加了关键上下文（比如“读取配置失败，原因：${original.getMessage()}，配置路径：/etc/app/config.yaml”）
- 自定义异常应继承合适的父类，并提供带 cause 和 message 的构造器
- 不要在 finally 块中抛出异常，它会吞掉 try 或 catch 中已抛出的异常
泛型：用好类型参数，但别试图绕过类型擦除
泛型是编译期保障，运行时不存在。因此不能用 T.class、不能 new T()、不能基于泛型类型做 instanceof 判断。若真需运行时类型信息，显式传入 Class
- 方法返回泛型集合时，优先返回不可变视图（Collections.unmodifiableList）或明确说明是否可修改
- 通配符要精准： extends Number> 表示“只读的数字”， super Integer> 表示“能写入整数的容器”
- 避免原始类型（如 List）——它放弃编译检查，且与泛型代码交互时可能引发 ClassCastException
异常与泛型结合：谨慎设计泛型方法的异常签名
泛型方法本身不改变异常规则。但要注意：不要因泛型而模糊异常含义。例如一个
立即学习“Java免费学习笔记（深入）”；
- 泛型方法抛出的异常应与其业务语义一致，不因类型参数变化而随意变更异常类型
- 避免在泛型类中捕获泛型相关的 ClassCastException 并“静默吞掉”，这通常掩盖了类型使用错误
- 如果泛型逻辑依赖运行时类型判断（如 JSON 反序列化），异常信息里应包含具体类型名（T.class.getSimpleName()），方便排查
不复杂但容易忽略
Effective Java 的建议从来不是“必须这么做”，而是“为什么这么选更少踩坑”。异常和泛型都是工具，它们的价值体现在团队协作时的一致预期和运行时更早暴露问题——而不是让代码看起来更“高级”。
