> In Go the code does what it says. The error is handled or it is not. You may find Go's error handling verbose, but a lot of programmers find this a great relief.
I'm sorry but you are on the wrong side of history on this question (and I happen to think you're also wrong in your characterization of exceptions).
Forcing callers to deal with error numbers right here right now only gives you the illusion of clarity and robustness but it gives you neither.
Every Go program I read is littered with "err,ok := Foo(); if err {}" every ten lines or so. It's brutally verbose and hides the intent of the code.
And it also forces callers to handle error codes that they might not be able to, while a caller a few stack frames above would do a much better job at it.
We learned all these lessons in the 90's, pity Go chose to ignore them.
I just want to point out that just because go lacks a good way of handling error conditions, doesn't mean exceptions are the best way. Haskell has exceptions, and I wish it didn't. Because it has better options for dealing with error conditions, like Maybe and Either. If you are checking for an error condition every ten lines, those are by far nicer than using exceptions.
I'm sorry but you are on the wrong side of history on this question (and I happen to think you're also wrong in your characterization of exceptions).
Forcing callers to deal with error numbers right here right now only gives you the illusion of clarity and robustness but it gives you neither.
Every Go program I read is littered with "err,ok := Foo(); if err {}" every ten lines or so. It's brutally verbose and hides the intent of the code.
And it also forces callers to handle error codes that they might not be able to, while a caller a few stack frames above would do a much better job at it.
We learned all these lessons in the 90's, pity Go chose to ignore them.