[ewg4345h43]

It looks like GO developers never heard about "not repeat yourself", because after almost each call in GO, you write boilerplate error checking code... So you end up writing at least 2 times more lines of code.

[agumonkey]

It was a very conscious decision by go devs. To enforce local error fixes instead of the usual wrap and throw the exception again.

[feffe]

The article is not about Go, although that was my guess before reading it as well.

[iwwr]

You can always... not treat errors or exceptions. You also create employment for oncall engineers and debugging tools, I'd call it a win-win-win :) /s

[habibur]

You need all those error check code if you want to recover from error -- regardless of whether the error is coming from exception or value.

If you don't want to recover, just throw it down the stack that will exit, then can you do that without exception too. Just call error() function on error which will print the error and exit(-1). No need for per-line error checking in this case too.

[tsimionescu]

Realistic options are not limited to "handle at every point of the call stack where an error is encountered" like Go and "end program execution as soon as an error is encountered". Most programs handle most errors by bubbling them up to some top-level event loop and presenting some variant of abort/retry/fail to users. Exceptions are tailor-made to cover this use-case.

[habibur]

> errors by bubbling them up to some top-level event loop and presenting some variant of abort/retry/fail to users

The pros and cons of this approach have been covered extensively in the last decade.

the points discussed were --

// <well what's the point of arguing on the net anyway??>

[dtech]

You don't need it everywhere. With both exceptions and error monads, you can have a happy-flow path that mostly leaves out the boilerplate, and handle errors at a reasonable point.

Go forces you to add even if you want to defer handling to a later point.