NOTE: This is a fork of github.com/ztrue/tracerr
Tired of uninformative error output? Probably this will be more convenient:
package main
import (
"io/ioutil"
"github.com/hermeznetwork/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)
}
Find more executable examples in examples dir.
import "github.com/hermeznetwork/tracerr"
err := tracerr.New("some error")
Or:
err := tracerr.Errorf("some error %d", num)
If
err
isnil
then it still benil
with no stack trace added.
err = tracerr.Wrap(err)
Stack trace will be printed only if
err
is of typetracerr.Error
, otherwise just error text will be shown.
This will print error message and stack trace if any:
tracerr.Print(err)
This will add source code:
tracerr.PrintSource(err)
It's able to set up number of lines of code to display for each frame, which is 6
by default:
tracerr.PrintSource(err, 9)
Or to set up number of lines before and after traced line:
tracerr.PrintSource(err, 5, 2)
The same, but with color, which is much more useful:
tracerr.PrintSourceColor(err)
tracerr.PrintSourceColor(err, 9)
tracerr.PrintSourceColor(err, 5, 2)
It's also able to save output to variable instead of printing it, which works the same way:
text := tracerr.Sprint(err)
text := tracerr.SprintSource(err)
text := tracerr.SprintSource(err, 9)
text := tracerr.SprintSource(err, 5, 2)
Stack trace will be empty if
err
is not an instance oftracerr.Error
.
frames := tracerr.StackTrace(err)
Or if err
is of type tracerr.Error
:
frames := err.StackTrace()
Unwrapped error will be
nil
iferr
isnil
and will be the same error iferr
is not an instance oftracerr.Error
.
err = tracerr.Unwrap(err)
Or if err
is of type tracerr.Error
:
err = err.Unwrap()
Stack trace causes a performance overhead, depending on a stack trace depth. This can be insignificant in a number of situations (such as HTTP request handling), however, avoid of adding a stack trace for really hot spots where a high number of errors created frequently, this can be inefficient.
Benchmarks done on a MacBook Pro 2015 with go 1.11.
Benchmarks for creating a new error with a stack trace of different depth:
BenchmarkNew/5 200000 5646 ns/op 976 B/op 4 allocs/op
BenchmarkNew/10 200000 11565 ns/op 976 B/op 4 allocs/op
BenchmarkNew/20 50000 25629 ns/op 976 B/op 4 allocs/op
BenchmarkNew/40 20000 65833 ns/op 2768 B/op 5 allocs/op