Hacker News Reader

Comment by navd | Hacker News Reader

I think this is where custom error types become useful. They can provide you more context about what went wrong so that you can handle that issue properly

View on HN

Not if my caller forgets to handle my error at all

If you care, you can't realistically forget. There are linters that will find your missed error checks.

In Go, if a function returns an error you have to explicitly handle or suppress it. Otherwise code just doesn't compile.

There's no margin to "forget".

That's not quite true. For instance, the error value returned from `fmt.Printf`[0] is usually ignored silently.

[0] https://godoc.org/fmt#Printf

It's true that functions that return (result, error) tuples are hard to miss the errors from, because you have to explicitly either at least accept it, or ignore it. It's both visually obvious that you've dropped the error and there are linters to catch this for you (which I highly recommend integrating into pre-commit hooks).

However, if a function just returns an error, but no result value, it is indeed easy to silently drop that error without realizing it by simply invoking the function and not catching the result at all. To which, again, I'd highly recommend using linters at commit time or even code save time.

> In Go, if a function returns an error you have to explicitly handle or suppress it. Otherwise code just doesn't compile.

ah, yeah, great idea. in practice this just means that most Go projects are minefields of

    if err != nil { panic(err) }

    if err != nil { return err }

ie a manual & repetitive implementation of assert for the first case and manual & repetitive implementation of an exception call stack for the second. thank you very much, I'll take the automated version known as exceptions instead.

Yes, Go requires explicit error propagation, but this is desirable because 1) errors are no different than other values so they don’t get special flow control and 2) people are much more likely to properly handle errors if they have to think about handling in every call frame (I.e., error handling bugs are much rarer in Go than Python or JS or etc).

>>> (I.e., error handling bugs are much rarer in Go than Python or JS or etc).

[citation needed]

I've been writing Python extensively for 10 years and Go for 6. Recently, I've been the exceptions cop in our Python/JS shop, and every week I see errors in prod that would almost certainly not exist in Go code (both because Go is statically typed but also because Go developers check their errors).

Take this anecdote for whatever it's worth to you.

This isn’t true. This is a valid program, after all—even though fmt.Println returns (int, error):

    func main() {
        fmt.Println(“Hello”)
    }

> In Go, if a function returns an error you have to explicitly handle or suppress it.

If a function only returns an error, or if it returns both a value and an error and you care for neither, you can absolutely ignore them entirely.

And when you can "suppress" an error and still access the value, it's not really impressive.

file, _ := ioutil.ReadFile(filename)

This is classic Go design, for better or worse. "Just use this ad-hoc, unprincipled tool to counter a shortcoming of the core language."

Properly handling things is about reverting all side effects to get to initial predictable state from where you can start over. Context doesn't help here. What helps is isolation or rather structuring your program around lightweight isolated processes. Where you can be sure that anything within process boundaries doesn't affect any other process and so you can just restart it if something blows up in it.

Reply on news.ycombinator.com