异常范围缩小指子类方法抛出的异常不得多于父类，如父类throws Exception，子类可缩小为throws FileNotFoundException或不抛异常，使调用方能精准处理异常、保障变量状态可控与逻辑清晰。
方法覆盖中异常范围缩小，核心是子类方法抛出的异常不能比父类方法更多，这是保障调用方逻辑稳定的关键。它不改变变量处理流程本身，但能防止因异常类型泛化导致的变量状态不可控、后续逻辑跳过或静默失败。
异常范围缩小的本质作用
父类声明了较宽泛的异常（如 Exception 或 IOException），子类覆盖时可只抛出其子类（如 FileNotFoundException）或完全不抛异常。这样做的实际效果是：调用方在编译期就能明确知道可能遇到哪些具体异常，从而针对性地保护变量初始化、赋值、清理等关键步骤。
- 若父类方法声明
throws Exception，调用代码常需用通用catch (Exception e)，容易掩盖变量未赋值、资源未释放等问题 - 子类缩小为
throws IllegalArgumentException，调用方只需处理业务校验异常，其余分支（如变量计算、对象构建）可放心执行，逻辑更清晰 - 子类选择不抛异常（
throws列表为空），意味着该实现已内部消化所有风险，变量生命周期完全由方法体控制，一致性天然增强
保持变量处理逻辑一致的实操要点
变量处理逻辑是否一致，取决于异常处理边界是否与变量作用域对齐。缩小异常范围本身不写代码，但它倒逼你把变量操作“收口”到可控范围内。
- 避免在 finally 块外提前返回或抛异常：确保变量赋值、转换、校验等步骤在异常发生前已完成，或在 catch 中提供默认值
-
用受检异常明确划分变量就绪阶段：例如父类定义
loadConfig() throws IOException，子类覆盖为loadConfig() throws ConfigNotFoundException，说明配置加载失败仅限“找不到”，而非“读取中断”或“解析失败”，变量解析逻辑可统一放在 try 块后 -
配合 final 变量或 builder 模式：当异常范围缩小时，可安全使用
final Config cfg = loadConfig();，后续所有变量操作都基于非空、合法的cfg，无需反复判空或重试
一个典型对比场景
假设父类有方法：
public String processInput(String raw) throws Exception { ... }子类覆盖为：
public String processInput(String raw) throws IllegalArgumentException { ... }调用方原先必须写：
try { result = service.processInput(input); } catch (Exception e) { log.error("未知错误", e); result = DEFAULT; }现在可精确写：
result = service.processInput(input); // 不再需要通用 catchif (result == null) { throw new IllegalStateException("处理结果不应为空"); }
变量 result 的赋值、校验、使用链条更紧凑，不会被宽泛异常打断或绕过。
