[masklinn]

> It's designed to force people to handle the damn error as near to the call as possible.

Except for not even remotely doing that:

1. if a call can fail but returns no useful value (or the caller cares little about it, and thus ignores everything it returns), Go will not complain that you're ignoring the return value entirely

2. if you have several calls which can fail, nothing forces you to actually handle all the errors, because Go doesn't check for that, it relies on the compiler error that a variable must be used:

    v1, err := Foo(false)
    if err != nil {
        fmt.Println("error")
        return
    }
    fmt.Println("first", v1)
    v2, err := Foo(true)
    fmt.Println("second", v2)

will not trigger any error, because the second calls simply reassigns to the existing `err`, which has already been used once, and thus is fine by the compiler.

[marcus_holmes]

Yeah it's a convention. It's not enforced by the compiler. It is caught by several of the static code checking tools (and some linters I believe). You can ignore the convention if you want (you probably shouldn't, but you can).

You could make the case that this is a footgun, sure. I prefer to think of it as giving me the right tools to make the right choice in my specific circumstances.