> This is simply false and a misconception held by people who haven't spent a lot of time with the language.

If you've spent a lot of time with the language, then you've surely noticed that people rarely do this (because it's extremely verbose). The language encourages ignoring errors in defer.

(Contrary to the parent post, I'm not sure this is a real problem, however.)

That is so cool. And confusing. And likely to lead to errors.

Error handling should not require l33t features. (This is my big argument with both Go and Rust. The stuff they use to get around not having exceptions is worse than exceptions.)

I wouldn't really call "return values" a "l33t feature".

Exceptions are absolutely a "l33t feature". They break whatever is currently happening. They are an uncontrolled return working its way up your structure.

While you're attempting to recover from that Exception I gracefully catch my error and can even use the multiple return values that came back successfully from my function, despite there being an error.

As though exceptions themselves are somehow not a "l33t feature". :P

That's right but you are not returning the error. Here is the corrected snippet https://play.golang.org/p/A3YRSTg-7K

Edit: your example works too, though I find it weird...