抛异常后属性值不变原因分析

本文深入解析了Java中setter方法抛出异常时属性值是否会被修改这一关键问题，明确指出：只要遵循“先校验、后赋值”的规范写法且不吞没异常，抛异常将严格阻止字段被修改，确保状态一致性；反之，若赋值前置、异常被静默捕获或缺乏并发控制，则可能引发隐蔽的脏数据风险。文章不仅揭示了底层执行逻辑的本质——异常仅中断流程而非自动回滚，更提供了可落地的防御策略，帮助开发者写出真正健壮、可预测的setter逻辑。

如果在 @dec2 对应的 setter 方法里抛出异常，属性值**不会被修改**——前提是 setter 逻辑写得规范，即赋值语句（this.field = value;）写在异常检查之后、且未被 try-catch 吞掉异常。

setter 抛异常时的典型执行流程

Java 中 setter 是普通方法，执行顺序严格按代码行。常见安全写法是：

• 先校验参数（如非空、范围、格式等）
• 校验不通过就 throw new IllegalArgumentException(...)
• 只有校验通过后，才执行 this.field = value;

此时一旦抛异常，赋值语句根本不会执行，字段保持原值（可能是初始值 null、0 或之前设过的有效值）。

容易出问题的错误写法

以下情况会导致“看似抛了异常，但属性却被意外改了”：

• 赋值写在检查前：比如先 this.field = value;，再校验并抛异常 —— 值已改，异常只是“事后补救”
• 异常被内部 catch 吞掉：setter 里用 try-catch 捕获并静默处理，没 re-throw，外部无感知，但字段可能已被设为非法值或默认值
• 多线程竞争下未加同步：一个线程刚完成赋值、另一个线程在检查时抛异常，但字段已变；这不是 setter 本身逻辑问题，而是并发控制缺失

如何确保属性值不变

最稳妥的做法是遵循“先验后赋”原则，并避免在 setter 内吞异常：

• 校验逻辑放在赋值语句之前
• 使用明确的运行时异常（如 IllegalArgumentException），不捕获也不处理
• 若需日志记录，可在抛异常前 log.warn(...)，但不要 catch
• 对关键不可变字段（如 ID、创建时间），考虑用 final + 构造器初始化，彻底规避 setter 修改可能

总之，抛异常本身不会自动回滚字段值，它只中断方法执行流；值是否改变，取决于你把赋值语句放在哪里、以及有没有意外覆盖。

以上就是《抛异常后属性值不变原因分析》的详细内容，更多关于的资料请关注golang学习网公众号！