How to get the stack trace pointing to actual error reason

Let's say I have some code like this:

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

In case err != nil I will get something like this:

panic: some error explanation here

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

This stack trace is completely legit but sometimes these error messages may not clarify what happened and so I'd like to dig deeper into the source code of the 3rd party library to investigate what exactly causes this error to be returned. However when my code panics like this, there is no way to get the actual place that returned this error.

A little bit more clarification: as I'm coming from JVM world where exceptions are thrown I can completely trace what exactly line of code thrown the exception and thus can easily find the place and see what gone wrong. Go stack trace ends exactly where my code panics and thus not too useful in my case.

I've created a playground here and ideally I'd like to be able to trace the error to the place it was actually returned from, not panic. (e.g. to line 17, return "", errors.New("some error explanation here"))

Is this even possible?

I think that there is an easier way to achieve this. You can try wrapping errors using the golang "default" third party library error package:

You need to define the interface to be implemented by your error :

type stackTracer interface {
    StackTrace() errors.StackTrace
}

Then use it when wrapping/processing an error :

err, ok := errors.(stackTracer) // ok is false if errors doesn't implement stackTracer

stack := err.StackTrace()
fmt.Println(stack) // here you'll have your stack trace

Following comment by mrpandey, there are other library that allows a certain degree of error handling :

• eris "is an error handling library with readable stack traces and flexible formatting support"
• go-errors/errors "adds stacktrace support to errors in go."
• palantir/stacktrace "Look at Palantir, such a Java shop. I can't believe they want stack traces in their Go code."

Shortly: this is not possible.
Since errors are values, they are not treated in any special way. Due to this, when function (normally) returns, stack is no more available (ie. another function call may overwrite memory used by returning-error function' stack).

There is a tool called trace which was introduced with go1.5, but for now, there is no comprehensive tutorial available neither any of those I found says that this kind of feature will be included.

As others have pointed out tracing errors in go isn't trivial. There are projects like juju/errgo, that allow you to wrap errors and then trace these errors back. For that to work tough, you must use them consistently throughout your project and that won't help you with errors in 3rd party libraries or with errors that get handled and never get returned.

Because this is such a common issue and I really got annoyed with this, I wrote a small debug utility that will add debug code to go files that logs every returned error (value that implements error) and the function in which it was returned to STDOUT (if you need more advanced logging just hack the logger in the project, it's really simple).

Installation

go get github.com/gellweiler/errgotrace

Usage

To debug all files in the current directory:

$ find . -name '*.go' -print0 | xargs -0 errgotrace -w

To remove the added debug code from the go files:

$ find . -name '*.go' -print0 | xargs -0 errgotrace -w -r

Then just simply compile & run your code or your test cases.

Sample Output

[...]
2017/12/13 00:54:39 [ERRGOTRACE] parser.*Parser.objectKey: EOF token found
2017/12/13 00:54:39 [ERRGOTRACE] parser.*Parser.objectItem: EOF token found
2017/12/13 00:54:39 [ERRGOTRACE] parser.*Parser.objectKey: EOF token found
2017/12/13 00:54:39 [ERRGOTRACE] parser.*Parser.objectItem: EOF token found
2017/12/13 00:54:39 [ERRGOTRACE] parser.*Parser.objectKey: At 3:4: nested object expected: LBRACE got: ASSIGN
2017/12/13 00:54:39 [ERRGOTRACE] parser.*Parser.objectItem: At 3:4: nested object expected: LBRACE got: ASSIGN
2017/12/13 00:54:39 [ERRGOTRACE] parser.*Parser.objectList: At 3:4: nested object expected: LBRACE got: ASSIGN
2017/12/13 00:54:39 [ERRGOTRACE] parser.*Parser.Parse: At 2:31: literal not terminated
2017/12/13 00:54:39 [ERRGOTRACE] parser.Parse: At 2:31: literal not terminated
2017/12/13 00:54:39 [ERRGOTRACE] hcl.parse: At 2:31: literal not terminated
2017/12/13 00:54:39 [ERRGOTRACE] hcl.ParseBytes: At 2:31: literal not terminated
2017/12/13 00:54:39 [ERRGOTRACE] formula.parse: parsing failed
[...]

As you can see from this output, it's really easy to tell in which function the error originally occurred. Once you know that, you can use a debugger to get more context.

Take a look at https://github.com/ztrue/tracerr

I created this package in order to have both stack trace and source fragments to be able to debug faster and log errors with much more details.

Here is a code example:

package main

import (
	"io/ioutil"
	"github.com/ztrue/tracerr"
)

func main() {
	if err := read(); err != nil {
		tracerr.PrintSourceColor(err)
	}
}

func read() error {
	return readNonExistent()
}

func readNonExistent() error {
	_, err := ioutil.ReadFile("/tmp/non_existent_file")
	// Add stack trace to existing error, no matter if it's nil.
	return tracerr.Wrap(err)
}

And here is the output:

package main

import (
	"errors"
	"fmt"
)

func main() {
	value, err := DoSomething()
	if err != nil {
		panic(err)
	}
	fmt.Println(value)
}

func DoSomething() (string, error) {
	return "", errors.New("some error explanation here")
}

The problem is the standard package errors does not attach the stack trace at the point it occurs. You can use github.com/pkg/errors to do that:

package main

import (
	"github.com/pkg/errors"
	"fmt"
)

func main() {
	value, err := DoSomething()
	if err != nil {
		fmt.Printf("%+v", err)
	}
	fmt.Println(value)
}

func DoSomething() (string, error) {
	return "", errors.New("some error explanation here")
}

$ go run stacktrace.go
some error explanation here
main.DoSomething
	/Users/quanta/go/src/github.com/quantonganh/errors/stacktrace.go:18
main.main
	/Users/quanta/go/src/github.com/quantonganh/errors/stacktrace.go:10
runtime.main
	/usr/local/Cellar/go/1.15.2/libexec/src/runtime/proc.go:204
runtime.goexit
	/usr/local/Cellar/go/1.15.2/libexec/src/runtime/asm_amd64.s:1374

More details: https://dave.cheney.net/2016/06/12/stack-traces-and-the-errors-package

Take a look at: https://github.com/efimovalex/stackerr

Is this the thing you are looking for?

package main

import "github.com/efimovalex/stackerr"
import "fmt"

func f1() *stackerr.Err {
	err := stackerr.Error("message")
	return err.Stack()
}

func f2() *stackerr.Err {
	err := f1()
	return err.Stack()
}

type t1 struct{}

func (t *t1) f3() *stackerr.Err {
	err := f2()
	return err.Stack()
}

func main() {
	ts := t1{}
	err := ts.f3()

	err.Log()
}

Result:

2017/08/31 12:13:47 Error Stacktrace:
-> github.com/efimovalex/stackerr/example/main.go:25 (main.main)
-> github.com/efimovalex/stackerr/example/main.go:19 (main.(*t1).f3)
-> github.com/efimovalex/stackerr/example/main.go:12 (main.f2)
-> github.com/efimovalex/stackerr/example/main.go:7 (main.f1)

As I know, stackrerror is the simplest stack display package. You can use all the native log library records or output the call stack yourself. For example:

    package main
    
    import "github.com/lingdor/stackerror"
    
    func act1()error {
    return stackerror.New("here Error")
    }
    
    func main(){
    err:=act1()
    fmt.println(err.Error()) //panic(err) and log.Info(err) are ok
    }

output :

*stackError.stackError : here Error
at main.act1( /Users/user/go/testMain/src/main/main.go:17 )
at main.main( /Users/user/go/testMain/src/main/main.go:22 )
at runtime.main( /usr/local/Cellar/go/1.13.4/libexec/src/runtime/proc.go:203 )

You can use the built-in Recover function to handle panic and print the stack trace.

From https://blog.golang.org/defer-panic-and-recover
> Recover is a built-in function that regains control of a panicking
> goroutine. Recover is only useful inside deferred functions. During
> normal execution, a call to recover will return nil and have no other
> effect. If the current goroutine is panicking, a call to recover will
> capture the value given to panic and resume normal execution.

I have modified your example to use recover and eris. Eris provides a better way to handle, trace, and log errors in Go.

package main

import (
	"github.com/rotisserie/eris"
	"fmt"
)

func main() {
	value, err := DoSomething()
	defer func() {
		if r := recover(); r!= nil {
			fmt.Println(fmt.Sprintf("%+v", r))
		}
	}()
	if err != nil {
		panic(err)
	}
	
	fmt.Println(value)
}

func DoSomething() (string, error) {
	return "", eris.New("some error explanation here")
}

The output is:

some error explanation here
	main.DoSomething: /tmp/sandbox147128055/prog.go: 23
	main.main: /tmp/sandbox147128055/prog.go: 9
	runtime.main: /usr/local/go/src/runtime/proc.go: 203
	runtime.goexit: /usr/local/go/src/runtime/asm_amd64p32.s: 523

See it in action here https://play.golang.org/p/jgkaR42ub5q

I can't believe no one mentioned the amazing cockroachdb/errors: a well-maintained library with the following features:

• Error chaining .Wrap()
• Error encoding: JSON, Sentry
• Mark error as "handled"
• Add a secondary error
• Stack traces
• Add contextual information to an error
• Add user-facing information: human-friendly text
• Generate PII-free details (without personally identifiable information)

Sample code:

package main

import (
	"fmt"

	"github.com/cockroachdb/errors"
)

// Leaf error: standard error
var LeafError = errors.New("Database error")

func main() {
	// Call a function that fails
	_, err := startTransaction()

	if err != nil {
		// Return a wrapped error with more information
		var returnedError = errors.WithHint(
			// Wrap the returned error with our standard error
			errors.CombineErrors(LeafError, err),
			// User facing error
			`Sorry, there is an issue. Please try again later.`,
		)

		// okay we'll actually print it. Use "%+v" to see stack traces.
		fmt.Printf("Error: %+v\n", returnedError)
	}
}

// Sample function that fails
func startTransaction() (any, error) {
	return nil, errors.New("Failed to start a transaction")
}

Sample output:

Error: Database error
(1) Sorry, there is an issue. Please try again later.
Wraps: (2) secondary error attachment
  | Failed to start a transaction
  | (1) attached stack trace
  |   -- stack trace:
  |   | main.startTransaction
  |   |         /home/kolypto/c0de/medthings/cerebellum/cerebellum/play.go:32
  |   | main.main
  |   |         /home/kolypto/c0de/medthings/cerebellum/cerebellum/play.go:14
  |   | runtime.main
  |   |         /usr/lib/go-1.20/src/runtime/proc.go:250
  |   | runtime.goexit
  |   |         /usr/lib/go-1.20/src/runtime/asm_amd64.s:1598
  | Wraps: (2) Failed to start a transaction
  | Error types: (1) *withstack.withStack (2) *errutil.leafError
Wraps: (3) attached stack trace
  -- stack trace:
  | main.init
  |     /home/kolypto/c0de/medthings/cerebellum/cerebellum/play.go:10
  | runtime.doInit
  |     /usr/lib/go-1.20/src/runtime/proc.go:6506
  | runtime.main
  |     /usr/lib/go-1.20/src/runtime/proc.go:233
  | runtime.goexit
  |     /usr/lib/go-1.20/src/runtime/asm_amd64.s:1598
Wraps: (4) Database error