ztrue / tracerr Goto Github PK

Go 1.13 supports wrapping errors in a standard way.

tracerr doesn't print stack traces of wrapped errors, as it doesn't know how to look inside to see the wrapped error is a tracerr.Error.

Changing the test in print.go from

        e, ok := err.(Error)
	if !ok {
		return err.Error()
	}

to

        var e Error
	if !errors.As(err, &e) {
		return err.Error()
	}

It's a fairly trivial change, but does mean that it won't compile with Go 1.12 or earlier, without some minor refactoring and build flags.

I made a spiritual successor of github.com/pkg/errors some time ago and in it I want to know if an error already contains a stack trace. The goal is that if a large codebase uses different packages for errors, they should work together and not hide existing recorded information, like a stack trace.

From what I am seeing in this package is that it has the same issue as github.com/pkg/errors: the return value of StackTrace() is a custom type defined in this package. So it is not possible to detect the error having this method without importing this package.

I would suggest that instead, the following interface is implemented:

type stackTracer interface {
        StackTrace() []uintptr
}

Then, it is easy to obtain a stack trace, use it, format it, and one does not have to depend on a library which created the error.

To prevent a breaking change, I have seen also the following interface being used in this package:

type goErrorsStackTracer interface {
	Callers() []uintptr
}

BTW, you are also using runtime.FuncForPC which is deprecated. And calling it runtime.FuncForPC at the time of making a stack trace is quite a performance hit. It is much better to just record a stack trace (into []uintptr) when making an error and then resolve addresses with runtime.FuncForPC when the stack is formatted (if ever).

would it be possible to add some missing functions like wrapf and errorf to match the interface of https://github.com/pkg/errors . then this can be a drop in replacement to that package.

thanks

Incredible project! Such a beautiful night and day difference.

Currently, we can control the amount of lines before and after the trace line in methods such as:

tracerr.SprintSourceColor(beforeLines, afterLines)

Is would be incredibly helpful if we could also specify the amount of stack frames printed. For example:

tracerr.SprintSourceColor(beforeLines, afterLines, stackFrameLimit)

Or some similar signature, getting everything every trace down to the runtime assembly is rather cool but in the majority of cases you only want the last 3-4 stack frames in any given trace for debugging. This will reduce output in terminal and show only the level of granularity we need.

Another potential attack vector which would potentially help performance:

Stack trace causes a performance overhead, depending on a stack trace depth

This could potentially be mitigated if an environmental variable such as STACK_FRAME_LIMIT was added to control the max stack length big-endian style. Only the last n stack frames would be tracked, and as a frame is added, the earliest frame is popped off. This would reduce the stack trace depth and potentially decrease performance overhead on deep traces.