I just want to see f(g(x), h(y)). I’m hoping for an editor that both generates and hides the twelve lines of noise that call g, handle an error, call h, handle an error, call f, and handle an error. I don’t want to write or review that for the same reason that stack frame setup just happens in code that nobody writes or reviews.
We could generate Go from some other language, but I can’t assume any team will buy into that.
I feel this way when writing business logic RPC services, because returning the error to the caller is almost always what you want to do.
Recently I wrote something very different, more low level. Rather than handlers it had a number of goroutines looping, selecting, and sending to channels. In this case explicit errors were a lot more useful. If it had been a language with exceptions and I had forgotten a try/catch, it could have killed one of my loops. Not good!
This is the kind of use case that fits well for Go. I think it’s a systems glue language that just happens to be friendly enough to invite abuse in mundane backend business logic tasks. But using it that way is setting yourself up for frustration.
I agree it this needs to happen. Right now about all you can do is snippet your way through it, it is an incredibly common scenario that go handles really poorly.
Java's Checked Exceptions was less invasive and API polluting than this is because at least it didn't get in the way of these types of calls where the error should just shortcut. More importantly in Java you could hide the errors behind a generic RuntimeException if from that point up there was nothing anything could do but generically deal with the error. Panic/Recover is similar but very discouraged for this sort of usage pattern.
We could generate Go from some other language, but I can’t assume any team will buy into that.