如何让堆栈跟踪指向实际的错误原因

大家好，我们又见面了啊~本文《如何让堆栈跟踪指向实际的错误原因》的内容中将会涉及到golang等等。如果你正在学习Golang相关知识，欢迎关注我，以后会给大家带来更多Golang相关文章，希望我们能一起进步！下面就开始本文的正式内容~

问题内容

假设我有一些这样的代码：

value, err := some3rdpartylib.DoSomething()
if err != nil {
    panic(err)
}

万一err != nil我会得到这样的东西：

panic: some error explanation here

goroutine 1 [running]:
main.main()
    /tmp/blabla/main.go:6 +0x80

此堆栈跟踪是完全合法的，但有时这些错误消息可能无法说明发生了什么，因此我想更深入地研究 3rd 方库的源代码，以调查究竟是什么导致了返回此错误。但是，当我的代码像这样发生恐慌时，无法获取返回此错误的实际位置。

再澄清一点：由于我来自抛出异常的 JVM 世界，我可以完全跟踪究竟是哪一行代码抛出了异常，因此可以轻松找到该位置并查看哪里出了问题。Go 堆栈跟踪恰好在我的代码发生恐慌的地方结束，因此在我的情况下不太有用。

我在这里创建了一个游乐场，理想情况下，我希望能够将错误追溯到它实际返回的地方，而不是恐慌。（例如到第 17 行，return "", errors.New("some error explanation here")）

这甚至可能吗？

正确答案

很快：这是不可能的。由于[错误是值](https://blog.golang.org/errors-are- values)，因此不会以任何特殊方式处理它们。因此，当函数（通常）返回时，堆栈不再可用（即另一个函数调用可能会覆盖返回错误函数堆栈使用的内存）。

go1.5 引入了一个名为 trace 的工具，但目前还没有全面的教程可用，我发现没有一个说会包含这种功能。

到这里，我们也就讲完了《如何让堆栈跟踪指向实际的错误原因》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于golang的知识点！