Discussion on: Go 2 Draft: Error Handling

[rhymes]

Hi Dean,

I'm a little conflicted on this.

First: instead of having the pattern var, err := method() now the code will be "littered" with var := check method(). I hope they can find a way to make that check implicit. I'm still not sure how I feel about those handle blocks, I've only skimmed the draft yesterday.

Second: I like this reaction about the whole thing:

Valentino Volonghi

@dialtone_

wat?

20:41 PM - 28 Aug 2018

00

Third: about handle blocks: think about reading the code after you wrote it, maybe weeks after. You read the code, and instead of seeing how the error is handled right there you need to jump up (hopefully not many levels) to see the various conditions, then you can resume reading the code, then you see another check so you go back up with your eyes to see what happens again with the error, then you resume, then you go back up again...

ps. you can add syntax highlighting to the code blocks, like:

// From the draft
func main() {
    handle err {
        log.Fatal(err)
    }

    hex := check ioutil.ReadAll(os.Stdin)
    data := check parseHexdump(string(hex))
    os.Stdout.Write(data)
}

this way:

[dean]

Implicit error checking is just kinda... bad. As a quote from the draft -

The subtleties of implicit checking are covered well in Raymond Chen’s pair of blog posts, “Cleaner, more elegant, and wrong” (2004), and “Cleaner, more elegant, and harder to recognize” (2005). In essence, because you can’t see implicit checks at all, it is very hard to verify by inspection that the error handling code correctly recovers from the state of the program at the time the check fails.

In terms of that reaction, I actually like that. Once a handle leaves scope, it should no longer be used.
I also think that defer should work the same way. A defer should execute when it leaves its scope, not when the function is done executing. It just makes more sense in my eyes and is much more intuitive.

For the syntax highlighting, I used a capital "G" on accident, I'll fix that!

[rhymes]

Implicit error checking is just kinda... bad. As a quote from the draft

I meant, implicit usage of check (you can derive which functions need a check if one of the return values is error) but still with explicit error handling.

But now, while writing this, I think I understood. If they remove the explicit check there's no way for the programmer to instantly figure out which method calls can trigger an error, unless they inspect the source code.

Using check also allows the compiler to throw errors if someone forgot to add check.