如何让SQL事务的InTx函数在回调发生Panic时保持安全？

这个用于SQL事务的InTx「上下文管理器」存在一个隐蔽的bug：当调用传入的Fun函数时发生panic，会导致错误的事务提交行为。

问题代码 #

type Fun func(context.Context, *sql.Tx) error

func InTx(db *sql.DB, fn Fun) error {
    ctx := context.Background()
    t, err := db.BeginTx(ctx, nil)
    if err != nil {
        log.Panicln(err)
        return err
    }
    return safe(ctx, t, fn)
}

// safe应在SQL事务上下文中执行传入的函数
// 仅当一切正常时返回nil错误
func safe(ctx context.Context, t *sql.Tx, fn Fun) (err error) {
    defer func() {
        if err == nil {
            err = t.Commit()
            return
        }
        if bad := t.Rollback(); bad != nil && bad != sql.ErrTxDone {
            err = fmt.Errorf("during rollback, panic(%v); err=%w", bad, err)
            // log error
            return
        }
    }()
    err = fn(ctx, t)
    return
}

问题演示示例 #

func main() {
    var db *sql.DB;
    // ... 初始化db
    _ = InTx(db, func(ctx context.Context, t *sql.Tx) error {
        // ... 执行更多SQL操作 ...
        if _, err := t.Exec("DELETE FROM products"); err != nil {
            return err
        }
        // ...
        panic("will cause Commit")
        // 此时应该执行Rollback()而非Commit，但当前逻辑会触发Commit
    })
}

Bug原因分析 #

当前safe函数的defer逻辑仅通过err变量是否为nil来决定提交还是回滚事务：

• 如果fn正常返回错误，err被赋值，defer会执行回滚；
• 但如果fn执行时触发panic，err变量会保持初始的nil状态，defer逻辑会误以为一切正常，执行Commit()，这完全违背了panic时应该回滚事务的预期。

修复方案 #

需要在defer中加入recover()来捕获panic，将panic转换为错误后再执行回滚逻辑：

func safe(ctx context.Context, t *sql.Tx, fn Fun) (err error) {
    defer func() {
        // 捕获panic并转换为错误
        if r := recover(); r != nil {
            err = fmt.Errorf("panic occurred: %v", r)
        }
        
        if err == nil {
            err = t.Commit()
            return
        }
        if bad := t.Rollback(); bad != nil && bad != sql.ErrTxDone {
            err = fmt.Errorf("rollback failed: %w; original error: %w", bad, err)
            // 此处应记录日志，而非触发panic
            log.Printf("rollback error: %v", bad)
        }
    }()
    err = fn(ctx, t)
    return
}

相关问题解答：在另一个panic期间触发panic是否合适？ #

结论：不合适
原因如下：

1. 程序崩溃风险：在panic的defer处理阶段再次触发panic，如果没有被后续的recover捕获，程序会直接崩溃，无法完成剩余的资源清理、错误上报等关键操作。
2. 错误信息丢失：Rollback失败本身是需要排查的异常，但如果此时触发panic，可能连Rollback失败的日志都无法正常输出，导致问题排查难度增大。
3. 破坏容错性：事务处理的核心目标是保证数据一致性，在异常场景下应优先尝试恢复或记录错误，而非直接终止程序，避免扩大影响范围。

什么时候合适？
只有当发生了完全不可恢复的致命错误，且继续执行会导致数据损坏、资源泄漏等更严重的后果时，才考虑在panic期间再次触发panic。这种场景极其罕见，通常都应该优先记录错误，让程序尽可能优雅地处理或退出。

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