I actually prefer exceptions to Go's approach, mainly because most of my code is structured with the best place to handle errors being higher up the call chain. Exceptions let me do that for free, whereas Go requires boilerplate code all over the call chain.

BTW your posting left out that close() can also fail (eg deferred writes run out of disk space).

And note that none of these really help with testing. In your 'cat' example, I'd want to test open failing, read failing, write failing and close failing. At a certain level the combination of language and libraries know these can fail. Ideally I would like to write zero lines of code to exercise those cases. In practise I usually find out that my test code is larger than the code being tested, and I usually have to add all sorts of instrumentation to force various failure modes which again makes my original code even longer and more obfuscated.

Go's panic/recover pattern lets you handle exceptions in the place you feel is best, much like exceptions. Though it is true that you would still need to check the error returned, and panic if not nil.

However, there are a few libraries that offer 2 versions of the same functions, one that returns the value and error combo, and one that panics in case of error and returns only the value (regexp' Compile and MustCompile for example). When it makes sense, it's nice to have this option.

Anyway, error handling is hard, I'm not a fan of exceptions, though alternatives such as Node's error as first argument of a callback and Go's second return value require polluting the normal code path. I like go's "defer" idea as a "finally", though.

We're interested in adding support for condition handlers. Arbitrary stack unwinding and/or first-class continuations aren't likely due to runtime/toolchain limitations, but the "register a function to be called on error, which might direct the call to be restarted" style is intended to be supported.