咨询：SqlDataAdapter.Update先触发RowUpdated事件再进入catch块的原因

这是SqlDataAdapter的正常执行逻辑，咱们来拆解一下背后的原因和应对方案：

1. 事件触发的核心逻辑 #

RowUpdated事件的触发时机是单条记录的数据库操作（插入/更新/删除）执行完毕后——这里的“完毕”指的是数据库命令执行结束，不管执行成功还是抛出异常。当你调用adapter.Update(Table)时，它会逐行处理DataTable里的变更：

• 对每一条变更行，先执行对应的SQL命令（比如你的Insert语句）
• 命令执行结束（成功或失败），立刻触发RowUpdated事件
• 如果命令执行抛出异常，事件触发完成后，异常才会被上层的try/catch块捕获

所以你的场景里，Insert命令执行失败抛出异常时，RowUpdated会先被触发，之后才进入catch块执行回滚逻辑。

2. 你的代码里的潜在风险 #

看你的RowUpdated事件处理方法，直接去取@SCOPE_ID参数的值，但如果Insert命令执行失败，这个参数的值大概率是无效的，甚至访问时会抛出新的异常，反而覆盖了原始错误，给调试带来麻烦。

3. 优化解决方案 #

你可以在事件处理中先判断当前行的操作是否成功，只有无错误时再处理自增ID：

void adapter_RowUpdated(object sender, SqlRowUpdatedEventArgs e) {
    // 先确认操作无错误，再处理自增ID
    if (e.Errors == null && e.StatementType == StatementType.Insert) {
        object ai = e.Command.Parameters["@SCOPE_ID"].Value;
        e.Row[_IdentityFieldName] = ai;
        // 标记该行状态为已完成，避免后续重复处理
        e.Row.AcceptChanges();
    }
}

另外，内层catch块重新包装异常时，建议保留原始异常的堆栈信息，方便定位问题：

catch (Exception ex) {
    trans.Rollback();
    // 保留原始异常作为InnerException
    throw new Exception("数据更新失败", ex);
}

总结 #

这个执行顺序是SqlDataAdapter的设计决定的——它希望你在每一行操作完成后（无论成败）都能有机会处理结果（比如记录日志、清理资源）。只要在事件处理中先判断操作是否成功，就能避免无效逻辑执行，同时保留原始异常信息便于排查问题。

内容的提问来源于stack exchange，提问作者GuidoG