如何确保 InTx 函数在回调期间避免恐慌？

小伙伴们对Golang编程感兴趣吗？是否正在学习相关知识点？如果是，那么本文《如何确保 InTx 函数在回调期间避免恐慌？》，就很适合你，本篇文章讲解的知识点主要包括。在之后的文章中也会多多分享相关知识点，希望对大家的知识积累有所帮助！

演示链接：https://go.dev/play/p/laqo-bff7sk

这很微妙，但是这个 intx“上下文管理器”（在事务中）至少有一个错误。如果在“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 should run the provided function in the context of a sql transaction
// expect a nil error if (and only if) everything worked w/o incident
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;
    // ...
    _ = InTx(db, func(ctx context.Context, t *sql.Tx) error {
        // ... lots more SQL executed here ...
        if _, err := t.Exec("DELETE FROM products"); err != nil {
            return err
        }
        // ...
        panic("will cause Commit")
        // should expect Rollback() instead, as if we:
        //return nil
    })
}

相关：在另一次恐慌期间恐慌是否不合适，例如如果回滚失败？如果是这样，为什么？ （或者当没有时）

正确答案

在另一个 defer 中添加 recover （在 safe 函数中的第一个 safe 函数之后，因为它们按堆栈顺序展开）将防止回调中出现“内部”panic，但这可能是次优的或不太惯用的其他方法.

defer func() {
    if veryBad := recover(); veryBad != nil {
        bad := t.Rollback()
        err = fmt.Errorf("aborted SQL due to panic: %v; err=%w", veryBad, bad)
        // log error, should re-panic here?
        return
    }
}()

我很乐意接受别人的 go 智慧来代替我可能存在缺陷的方法。

好了，本文到此结束，带大家了解了《如何确保 InTx 函数在回调期间避免恐慌？》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多Golang知识！