Go: Improve error handling

[omarkohl]

Right now I'm wrapping with fmt.Errorf("%w") and using go-multierror to convert multiple errors into one.

Dave Cheney says he no longer wraps. Why? What is the alternative? github.com/pkg/errors is archived. https://groups.google.com/g/golang-nuts/c/FjtjR87-1qM

https://dr-knz.net/cockroachdb-errors-everyday.html
https://github.com/cockroachdb/errors
cockroach package seems a little bloated. Many others don't seem to be tracking the stack trace al all?

https://www.southcla.ws/go-error-wrapping/
Looks nice: https://github.com/Southclaws/fault
Has stack, has user friendly messages, but seems a rather new project, is it worth adding as a dependency?

Ideally what I would like:

• Easy debugging when errors occur (stack trace or similar)
• Nice (non-technical) error messages for end users
• Not having to rip out the entire guts when some third-party dependency dies. Error handling is everywhere.
• Support for multi errors (e.g. when validating user input that contains multiple errors). In all fairness, this is an exceptional case, not the rule. Go 1.20 added some support for this, but the corresponding libraries still need to implement it. The main downside of the stdlib errors.Join() function is that the errors are separated with a newline when calling Error(), which breaks usual formatting and logging.

[omarkohl]

fault is also considering how to integrate multierror libraries Southclaws/fault#9

Some other links that I wrote down somewhere:

• https://earthly.dev/blog/golang-errors/
• Package errors looking for new maintainers pkg/errors#245
• Future of pkg/errors after proposal ? pkg/errors#202
• https://awesome-go.com/error-handling/

[omarkohl]

https://github.com/rotisserie/eris

• ✔️ Flexible formatting, including for stack traces, including JSON
• ❌ No multi error support. It does not seem on the roadmap right now Implement new API (from errgroup and multierror) so eris can become ultimate error package. rotisserie/eris#101
• ✔️ Popular (1.3k stars on GitHub)
• ❌ On the whole, there does not seem to be much active development right now (probably it just works well for its use case)
• ❌ No information for end users

[omarkohl]

The most promising alternative right now is indeed https://github.com/cockroachdb/errors .

• ❌ A little bloated for our use case i.e. it covers things that I don't need e.g. sending errors over the network. Solution: Limit ourselves to the parts we need. Possibly write an internal wrapper package that minimizes the interface.
• ✔️ Allows including information for end users i.e. WithHint() and WithDetail()
• ✔️ A little multi-error support already exists WithSecondaryError() and CombineErrors(). Work on Go 1.20 multi-errors is in progress. Question: Will support Go 1.20: wrapping multiple errors? cockroachdb/errors#99 Add Go 1.20 errors.Join support cockroachdb/errors#106 support multi-cause errors in go 1.20 cockroachdb/errors#112
• ✔️ Popular 1.7k stars on GitHub
• ✔️ Includes stack traces
• ✔️ Very thorough design document and article series by the maintainer of the library on the problems with Go error handling and how this lib solves them. Meaning that quite a bit of thought was put into the lib.
  • Part 1: The Go standard error APIs
  • Part 2: Go’s formatting APIs
  • Part 3: The Go error printing catastrophe
  • Part 4: Beyond fmt.Errorf()—everyday error objects in Go
• ✔️ The maintainer https://github.com/knz seems quite active e.g. when dealing with the multi-error integration.

[omarkohl]

https://github.com/Southclaws/fault

• ✔️ Allows including information for end users
• 🟡 Multi-error support is being considered Play nicely with multierror libraries Southclaws/fault#9
• 🟡 Instead of entire stack traces it includes information about the line where the error was created
• 🟡 Only a year old (June 2022), essentially single maintainer. Can be good because less baggage, but project is also more likely to disappear.
• ❌ Contains more stuff (context, tags) than I need, but I don't need to use it.

[omarkohl]

Writing our own error lib.

• ✔️ Only include what is really needed. Independence.
• ❌ Re-invent the wheel.
• ❌ Maintenance effort.

Some code I played around with. Note that there are a few open questions e.g. is a public Tree interface needed? Should the user friendly errors be part of the default type or a new optional type? Is having the simple location (source code line) of the error better than a full stack trace (taken from fault library)? Should the public functions return a type Tree or better error even if more internal casting would be required? Should recursion be replaced with loops?

type Tree interface {
	Error() string
	FriendlyError() string
	Unwrap() []error
	Location() string
}

func New(msg string) Tree {
	return new(msg, "")
}

func new(msg, friendlyMsg string) Tree {
	return defaultTree{
		msg:         msg,
		friendlyMsg: friendlyMsg,
		location:    getLocation(4),
		children:    nil,
	}
}

func NewFriendly(msg string, friendlyMsg string) Tree {
	return new(new, friendlyMsg)
}

// Newf includes formatting specifiers.
func Newf(message string, va ...any) Tree {
	return new(fmt.Sprintf(message, va...), "")
}

func Wrap(err error, msg string) Tree {
	return wrapMulti([]error{err}, msg)
}

func WrapMulti(errs []error, msg string) Tree {
	return wrapMulti(errs, msg)
}

func wrapMulti(errs []error, msg string) Tree {
	allNil := true
	for _, e := range errs {
		if e != nil {
			allNil = false
		}
	}
	if len(errs) == 0 || allNil {
		return nil
	}
	var children []Tree
	for _, e := range errs {
		if child, ok := e.(Tree); ok {
			children = append(children, child)
		} else {
			children = append(children, externalError{err: e})
		}
	}
	return defaultTree{
		msg:      msg,
		location: getLocation(4),
		children: children,
	}
}

type defaultTree struct {
	msg         string
	friendlyMsg string
	location    string
	children    []Tree
}

func (t defaultTree) Error() string {
	switch len(t.children) {
	case 0:
		return t.msg
	case 1:
		return fmt.Sprintf("%v: %v", t.msg, t.children[0].Error())
	default:
		var cMsgs []string
		for _, c := range t.children {
			cMsgs = append(cMsgs, c.Error())
		}
		return fmt.Sprintf("%v: [%v]", t.msg, strings.Join(cMsgs, " | "))
	}
}

func (t defaultTree) FriendlyError() string {
	switch len(t.children) {
	case 0:
		return t.msg
	case 1:
		return fmt.Sprintf("%v %v", t.msg, t.children[0].Error())
	default:
		var cMsgs []string
		for _, c := range t.children {
			cMsgs = append(cMsgs, c.Error())
		}
		return fmt.Sprintf("%v (%v)", t.msg, strings.Join(cMsgs, " ; "))
	}
}

func (t defaultTree) Unwrap() []error {
	var errs []error
	for _, c := range t.children {
		errs = append(errs, c)
	}
	return errs
}

func (t defaultTree) Location() string {
	return t.location
}

// externalError wraps errors not created by 'errtree'.
// It adds no information and acts as a transparent gateway.
type externalError struct {
	err error
}

func (t externalError) Error() string {
	return t.err.Error()
}

func (t externalError) FriendlyError() string {
	return ""
}

func (t externalError) Unwrap() []error {
	return []error{t.err}
}

func (t externalError) Location() string {
	return ""
}

func getLocation(skip int) string {
	pc := make([]uintptr, 1)
	runtime.Callers(skip, pc)
	cf := runtime.CallersFrames(pc)
	f, _ := cf.Next()

	return fmt.Sprintf("%s:%d", f.File, f.Line)
}