move from standard errors to xerrors

[tharvik]

Even though go 1.13 included some new features into the standard errors package, the trace feature available in xerrors is not there.

For this reason all errors.New messages should be replaced with xerrors.New messages.

[ineiti]

In fact we need to do the inverse: only xerrors.New and xerrors.Errorf allow to have the error-stack included...

[tharvik]

FYI, there is also https://github.com/JavierZunzunegui/zerrors which is stable, see discussion on golang.

[nkcr]

I also stumbled upon this one: https://github.com/cockroachdb/errors

[ineiti]

Oh my - they grow like the ulcers in my stomach when I work on typescript!

• xerrors - works so far, even if I'm not a big fan of how it prints the frame
• zerrors - new kid on the block - no changes in the last 6 months, method-names seem to mix Wrap with the frame
• errors - has it all, but might be overkill - also I don't like the namespace clashing with the go errors

Please add your vote:

• @ineiti - xerrors
• @nkcr - xerrors
• @tharvik - errors
• @cgrigis - xerrors

[ineiti]

@tharvik why errors? Don't you like the trace feature of xerrors to know where it all happened?

[tharvik]

@tharvik why errors? Don't you like the trace feature of xerrors to know where it all happened?

I meant the errors from https://github.com/cockroachdb/errors

But yeah, I prefer the basic golang's errors. I think we can quite precisely know where an error happened just by looking at the resulting string. Each time a check for error is done, a context is added using fmt.Errorf, which is way more readable than a full stacktrace.

[ineiti]

which is way more readable than a full stacktrace.

Hmm - when debugging, I like having a list of methods and files where the error got passed up to. It helps me to faster dig into where the problem might actually be happening. If I just have the context, a la:

context 1: context 2: context 3: context 4: actual error

I first have to search for each context, decide if it's actually a problem, and then move on. If I have

file1: method1: line1: context 1
file2: method2: line2: context2
file3: method3: line3: context3
file4: method4: line4: actual error

I can directly scan the methods and decide where to jump in...

[tharvik]

context 1: context 2: context 3: context 4: actual error

I first have to search for each context, decide if it's actually a problem, and then move on.

Then the contextes aren't helpful/detailed/relevant enough :P

That's mostly a matter of taste IMO, it is a small preference for me, so, your call :)

[nkcr]

Then the contextes aren't helpful/detailed/relevant enough :P

Just to add my grain of salt, this is exactly what I think and said back then when we choose to move to xerrors. If your context is well written (ie. never do a return nil, err and always use a nice wrapping message), then you should have no problem seeing where the error happened.
But since we changed, my opinion is we should stick to that for the moment.