Comment by dullgiulio | Hacker News Reader

Comment by dullgiulio | Hacker News Reader

Parent Full thread

A cursory look at the article, shows that the most important observation about error handling in Go is missing.

Errors should be "decorated" (wrapped, contextualized...) in 99% of the cases.

In the end you get errors that describe step by step what your program tried to do and why it failed, for example:

* could not load profile: could not open file: permission denied.

* could not download profile image: could not open URL: HTTP GET failed: network is down.

This has many advantages:

1. Much more readable than stack traces (especially if they include source file and line information or exception class names: users don't care about those.)

2. Errors are still easy to grep in code to work out the program flow (the stack trace, basically.)

3. When reading the code, you can see from the error context strings what the code is actually doing. Basically it serves a function of comments and (unlike comments) error strings remain up to date.

It is definitely verbose, especially the not equal nil part, as it's a result of Go attempt not to have special cases. Also it's a pity that errors can be silently ignored: maybe Go2 could be stricter here.

Overall, I think this is one of the best approaches at error handling.

In my experience, this just becomes arbitrarily close to "re-implement your stack trace by hand with space-delimited words instead of camelCaseFunctionNamesOrWhatever".

I'll overwhelmingly prefer an always-correct stacktrace over a hand-recreated one that sometimes collapses multiple branches into a single ambiguous on. At least then the devs can help me when it fails. And stack traces and concatenated strings are in no way appropriate error responses for humans unless you're expecting them to be able to navigate the source code, so neither does anything for the "provide a helpful error message for non-programmers" problem.

---

this is why stuff like https://github.com/pkg/errors exists. wrap at the deepest level / where the error originates, and it's relatively rare that you need to add context at higher levels. If you want user-friendly errors, you need something dramatically more sophisticated.

Just using WithStack() from "github.com/pkg/errors" on any error that originates from outside my repository has been my go-to rule for any Go project. It has never disappointed.

Like an exception?

Except it's just a returned value and not a goto lookalike.

Exceptions—which go straight up the call stack, like returns—are nothing like gotos.

The similarity in both needing to have stack trace does not make them very alike yet. They serve similar purpose and for that purpose the stack trace serves value to the developer.

Returns go straight up the stack only if you choose them to. Caller doesn't have to propagate errors and return immediately, it can hold onto them and/or process them in the natural place they occur, they are just values. The returns from your function can be found with "grep return".

Exceptions, by default, break the natural control flow unless you wrap everything with try/catch. Even then, a lot of constructs won't be very natural and you really will have to get out of your way to identify the source of the exception, which very frequently is more important than it's type.

Why would finding the source of the exception be difficult? The stack trace in exception-based languages goes back to the actual line, as opposed to a stack trace from an error-as-value based language, where it only goes to where you trigger generating the stack trace.

I meant finding it in the context of a coder who writes a function. It's hard to identify which expression and statements can cause exceptions and effectively short-circuit your function. In contrast to explicit errors-returned-as-values.

(Panics of course can cause similar thing in Go but that's the reason why they should rarely be recovered and not used as a value propagation mechanism.)

Is that any worse than the ambiguity in e.g. code like this?

    func thing(arg) {
      otherThing(arg) // does this return an error you're ignoring?
    }

It even has a similar problem, where void returns -> err returns on code changes are not visibly discoverable (similar to a newly-throwing func).

Granted, you could turn this into a compiler error. But it's not currently.

---

Anyway. Given that so many not-prevented-by-the-typesystem operations panic, I don't think it's reasonable to assume that any func call will not panic, especially not in the future since they may change. So you already have to program with `defer` to maintain your invariants, which is exactly the same as with exceptions, except you now have to deal with both possibilities for nearly every func.

Reply on news.ycombinator.com