
Eris – A better way to handle, trace, and log errors in Go - sum2000
https://github.com/rotisserie/eris/tree/v0.1.0
======
awinter-py
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.

Automatic stack capture for exceptions is something my language could
conceivably do on my behalf.

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 _much_ easier to use than Whatever() returning (type, err)

~~~
EdwardDiego
What surprises me as a primarily JVM developer now supporting Go apps and
dabbling in Go development is that the logging libraries (like klog) I've
encountered don't support the level of configuration I'm used to in JVM apps.
I miss being able to configure individual loggers at desired levels with a
logback.xml in the JAR, but especially the ability to change logging levels at
runtime.

I guess it's part of the Go philosophy - more dynamic logging would most
likely incur relatively higher performance costs.

~~~
alaties
You might wanna look at using something like zap instead, as it enables you to
do runtime loglevel changes...

~~~
EdwardDiego
Cheers for my development, I'll do that :)

------
bouncycastle
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?

~~~
zeta0134
Ehh, I'm not convinced the vocabulary there fits. An error _can_ be an
exception, if it was unexpected. That's the real distinction: errors are
expected and can (optionally) be handled explicitly. Anything unexpected, in
your code or within a library function, is an exception and should bubble up /
halt execution. But the trouble is that _expectedness_ isn't often a language
construct, but more like business logic, and will have different meanings (and
presumed severity) between library author and end user.

I think there are a lot of schools of thought on this precisely because it is
a difficult problem to solve: it requires getting a bunch of programmers to
agree about how the edge cases should be handled, and that's no small feat.

------
morningvera
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

You can reach out to us on slack (gorotisserie.slack.com/archives/CS13EC3T6)
for additional comments and feedback. Thanks!

~~~
nicpottier
Looks nice! Any plans to add support for uploading stacks to Sentry? That's a
must have for us and why we are using pkg/errors.

~~~
morningvera
Thanks! We'd love to add support if you need it. I'll make a note of it but
feel free to add an issue for it if you have time!

------
erik_seaberg
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).

------
caylus
This is really cool! My company has a similar internal library but it doesn't
format wrapped errors as well as Eris.

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?

------
directionless
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?

It seems to have a bit of a cleaner presentation in the error stack -- Its an
array, which feels nicer than a string.

------
chetanhs
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()

~~~
sangnoir

      import errors "github.com/morningvera/eris"

~~~
chetanhs
Yes it can be import aliased everywhere. But my point is it’s not needed.

------
mirimir
I wonder if they picked "Eris" based on Greg Hill's _Principia Discordia_.

~~~
mirimir
I did see that it's named after the Greek goddess Eris.

It's just that she isn't a major goddess, and is famous only for her "apple of
beauty" trick. And outside classical scholars, that's arguably via _Principia
Discordia_.

So I'm curious.

------
lowmagnet
IDK about the error json, looks too much like a PHP dump when a descriptive
error wrapper will do.

~~~
holaatme
If you are reading the JSON yourself, you’re doing it wrong. JSON logs can be
parsed and stored for analysis and generally deal with multi line issues much
better than any non json.

~~~
EdwardDiego
Bingo, we emit all our logs as JSON for ingestion into ES to allow easy
analysis.

