News for hackers. Stuff that matters.
Re:My Go Resolutions for 2017 by davekeck on Wednesday January 18, 2017 @01:12PM (#13428663)
Regarding error context: I'd advocate simple error-chaining using a linked list. If a function fails, it returns an error wrapping the underlying error as the cause, and so on up the stack. The top of the stack can inspect or print the error chain ("A failed because B failed because ..."), or pinpoint the error that was the root cause.

I would love for Go to include something like this:

    type Error struct {
        Description string
        Cause       error
    }
    
    func NewError(cause error, descriptionFmt string, args ...interface{}) error {
        return Error{
            Description: fmt.Sprintf(descriptionFmt, args...),
            Cause:       cause,
        }
    }
    
    func (me Error) Error() string {
        if me.Cause == nil {
            return me.Description
        }
        return fmt.Sprintf("%v: %v", me.Description, me.Cause.Error())
    }
    
    func RootCause(err error) error {
        if err, ok := err.(Error); ok && err.Cause != nil {
            return RootCause(err.Cause)
        }
        return err
    }
Re:My Go Resolutions for 2017 by bjacokes on Wednesday January 18, 2017 @08:54PM (#13432305)
Re:My Go Resolutions for 2017 by bmurphy1976 on Wednesday January 18, 2017 @09:40PM (#13432509)
Great library.
Re:My Go Resolutions for 2017 by rogpeppe1 on Thursday January 19, 2017 @07:39AM (#13435261)
or gopkg.in/errgo.v1 which is a bit more opinionated about error causes.
Re:My Go Resolutions for 2017 by tptacek on Wednesday January 18, 2017 @01:51PM (#13429132)
Many Go error libraries exist mostly to provide this kind of functionality.