Go中无需修改库代码，如何处理require包触发的断言？

为什么你的recover没效果？ #

testify的require.NoError这类断言，在失败时的逻辑是：先触发panic，紧接着在内部的defer函数里调用os.Exit(1)直接终止整个进程。你的外层defer recover还没来得及执行，程序就已经退出了，所以完全没机会处理。

解决方案 #

方案1：修改libraryFunction为assert包（不影响其他用户） #

如果你能修改libraryFunction的源码，但不想改变它对其他用户的行为，可以把require.NoError替换成assert.NoError。testify的assert包断言失败只会触发panic，不会调用os.Exit，这样你的外层recover就能正常捕获并执行恢复步骤。

修改后的libraryFunction示例：

func libraryFunction(...) ... {
   ...
   assert.NoError(t, some_condition) // 替换require为assert
   ... 
}

其他测试代码调用该函数时，依然会因为panic导致测试失败；而你的myFunction里的recover可以正常捕获panic并处理。

方案2：拦截os.Exit（无需修改libraryFunction） #

如果完全不能修改libraryFunction，可以通过全局替换os.Exit函数的方式，让它在被调用时触发panic而非直接退出，这样你的recover就能捕获。注意这种方式不适合并发场景，因为os.Exit是全局变量，并发调用会互相干扰。

示例代码：

import "os"
import "fmt"

func myFunction(...) ... {
    // 保存原始的os.Exit函数
    originalExit := os.Exit
    defer func() {
        // 恢复原始的os.Exit，避免影响其他逻辑
        os.Exit = originalExit
        if e := recover(); e != nil {
            do_some_recovery_step
            // 可根据需求添加错误处理逻辑，比如返回错误
        }
    }()

    // 替换os.Exit为自定义函数，触发panic而非退出
    os.Exit = func(code int) {
        panic(fmt.Sprintf("require assertion failed, exit code: %d", code))
    }

    libraryFunction(...)
}

方案3：隔离执行环境（适合非关键逻辑） #

如果上述方法都不适用，可以把libraryFunction的调用放到独立子进程中执行。通过exec.Command启动子进程运行相关逻辑，然后通过进程退出状态判断是否发生断言失败，主进程不会被终止，还能处理错误。不过这种方式开销较大，仅适合非性能敏感场景。

总结 #

• 无法直接用recover处理require包的断言失败，因为它会直接调用os.Exit终止进程。
• 最优方案是改用assert包（如果能修改libraryFunction），否则可以通过拦截os.Exit的方式处理，但要注意并发安全问题。

内容的提问来源于stack exchange，提问作者Alvaro Palma Aste