I don't see how pluggable or proxying support your argument. What would be the alternative that would more clearly communicate intent and avoid bugs? Just avoiding these constructs altogether isn't an answer to this question. Yes, some constructs/patterns should generally be avoided, but when they are necessary higher level constructs like these are a boon rather than a hindrance.
>Keep in mind that the worst problem is actually with badly caught exceptions.
My point here was that if we granted that checked exceptions, i.e. forcing handling of an exception by the compiler, is a net negative, the construct of exceptions themselves (sans forced handling) is still superior to error codes for the reasons I mentioned.
when they are necessary higher level constructs like these are a boon rather than a hindrance.
We are not in disagreement. Higher level constructs become a nuisance when they aren't really necessary: In other words, when the cost/benefit doesn't work out. Pluggability and proxying are cited as a nuisance when they should not have been there in the first place, often put there by junior programmers who are excited at their discovery. You can think of exceptions as a higher level construct expected to appear everywhere. This makes them more prone to abuse than proxying, for instance.
the construct of exceptions themselves (sans forced handling) is still superior to error codes for the reasons I mentioned.
Again, this is still relative to cost/benefit in individual situations. In the case of go, there would be other costs external to the simplicity of code.
>Keep in mind that the worst problem is actually with badly caught exceptions.
My point here was that if we granted that checked exceptions, i.e. forcing handling of an exception by the compiler, is a net negative, the construct of exceptions themselves (sans forced handling) is still superior to error codes for the reasons I mentioned.