That's the right approach, but it's still decades behind what a decent programming language would give you for free. You have to copy-paste that "errWriter" definition for every possibly-error-raising method that you want to call, because go has no generics. If you want to write to two different writers, let alone a list of them, then you have to go back to the function-and-variable version, which is very boilerplatey and impossible to reason about when refactoring.

This just shows that, to avoid having do-and-check after every operation, the provider needs to invent several idioms because it's tedious to the consumer.

But now the consumer needs to know multiple idioms and recognise when they are being used. And the reader of the consumer code needs to know that the normal `err != nil` idiom is not being followed. All of which requires everyone involved to do more reading of source code than a "throws" line.

How is this simpler than having a single, universal concept of exception handling?

Your link describes (and encourages) exactly the laborious emulation of Checked Exceptions that I was talking about in my above comment.

It doesn't make the guard clauses disappear. It merely forces the programmer to manually aggregate them at a higher level with even more boilerplate code.

If my guard clause is doing the same thing for 20 lines, it increases readability. Could be an optimization point too!

> https://blog.golang.org/errors-are-values

The "helper" function there introduces 10 lines of code (per function in which you want it), and doesn't even work if you call anything besides that one `write` in sequence.