Couldn't f check for g's errors?

Sure it can, http://play.golang.org/p/T6WIcT_8q5 works just fine!

No because you can't easily pass multiple return values as parameters. So annoying...

Actually you can: https://play.golang.org/p/a-qhe_vRvo

Oh my god...is that new? I swear I've tried that and it didn't work. You are my new hero.

[edit]

Though maybe I was thinking of adding parameters like https://play.golang.org/p/FKUMlQzCI5

In any case 'thebaer continues to be my hero.

It's how html/template.Must works, isn't it?

We have a small library of functions for sweeping up error returns, and for collecting errors from multiple functions and checking them all at once. It helps a lot.

Golang is very much on to something with it's "errors are values" philosophy, but I'd be the first to acknowledge that it's not a fully baked philosophy. It is weird to discover fundamental things about how to structure basic code several years into writing in a language, but that happens somewhat regularly with Go.

I could justify my ignorance by pointing out that for all the time I've spent using Go with http, I've not had occasion to use it for html. But, that would only mask my utter embarrassment at missing a core language feature, and worse yet something I complain about as a weakness of Go.

I'll be over here muttering to myself about monadic error values...don't mind me.

Would you, by chance, be able to link or share that error lib? I'd love to see more solutions for error handling to get a better grasp.

Haha, I'll take it. Go forth and wield your new power! I'm not able to find anywhere official documenting it, but yeah I don't believe it's new.

Edit: prodigal_erik found it: https://golang.org/ref/spec#Calls

Thanks, I've never seen that used and didn't know they special-cased it until I found https://golang.org/ref/spec#Calls. I wonder why it's not more common...

I'm sure there are good uses for it, but I personally haven't found one yet. I mostly use Go's multiple return values to also return errors -- and that's really like using checked exceptions in Java. So whether it's a try/catch or an if statement, you have to code for these things one way or another.

A try-catch block can cover many complex statements and pushes the recovery code down where you aren't forced to continually reread it. Even if it's possible to write concise Go, nobody seems to be interested in trying, it always seems to become a mess that spends 2/3 of its time on errors.

¯\_(ツ)_/¯ I'm personally a fan of the style, and like explicitly seeing where the fault points in functions are, rather than having to memorize what exceptions might get thrown by what. But it can definitely cover many complex situations.

That sucks to see people making a mess with error handling code, but there are examples of good uses out there. This [0] is one I quickly found.

[0] https://github.com/schachmat/wego/blob/master/we.go