Have spent a while in the py/js world but have switched to rust/go for part of this year -- biggest change is boilerplate relating to error handling.<p>Automatic stack capture for exceptions is something my language could conceivably do on my behalf.<p>Writing even 3 lines of code per function to propogate up the error is a huge pain, especially because it pollutes the return type -- MustWhatever() in go is <i>much</i> easier to use than Whatever() returning (type, err)
I think a lot of programmers (and languages) confuse errors and exceptions. In most cases, errors should be expected, like an End Of File error or socket disconnect error, they aren't really exceptions. You don't really want a stack trace if an EOF happens, so you? When there really is an exception, why not just use panic and let it bubble up?
My friend and I have been working on eris for a while and we’re very excited to get feedback from fellow gophers.
eris provides a better way to handle, trace, and log errors in Go. More info here github.com/rotisserie/eris and godoc.org/github.com/rotisserie/eris<p>You can reach out to us on slack (gorotisserie.slack.com/archives/CS13EC3T6) for additional comments and feedback. Thanks!
Stack traces and structured output are handy, but I was hoping for a way to factor out the handler boilerplate that makes app code unreadable (like the "check" or "try" proposal for future versions).
This is really cool! My company has a similar internal library but it doesn't format wrapped errors as well as Eris.<p>One other issue I've struggled with is in propagating errors across goroutines. If an error is created in the child routine, `runtime.Callers` doesn't include any stack frames from the parent. Assuming the parent wraps the error, it sounds like Eris would give you at least one line of the parent stack trace. Does it handle this specifically by including all of them?
I'd love to see a bit of the docs telling me how this improves on pkg/errors and go 1.13. At first pass, I'm not sure?<p>It seems to have a bit of a cleaner presentation in the error stack -- Its an array, which feels nicer than a string.
This looks pretty good. And I also get the reason behind it’s name. But for a utility package like this, it’s better if it was named errors. It makes the usage and call sites clear. Ex: eris.New() vs errors.New()