

Defer, Panic, and Recover - Go blog - pufuwozu
http://blog.golang.org/2010/08/defer-panic-and-recover.html

======
thristian
That's odd. It's clearly a system _like_ exception-throwing, but without the
ability to distinguish from different kinds of errors (say, one might be able
to recover from "received malformed input" but not from "array index out of
bounds"), and still requiring that programmers check the error return value of
most functions they call.

I wonder why they preferred that approach over the Java/Python approach to
exceptions.

~~~
frognibble
The reasons for not using exceptions are covered here:
<http://golang.org/doc/go_lang_faq.html#exceptions>

~~~
thristian
"We believe that coupling exceptions to a control structure, as in the try-
catch-finally idiom, results in convoluted code. It also tends to encourage
programmers to label too many ordinary errors, such as failing to open a file,
as exceptional."

To me, that comes across as "We don't like traditional exception handling
because languages that use exceptions for error-handling encourage programmers
to use exceptions for error-handling." Well, yes, that's what they're _for_.

Python's exception system is far from perfect - it would be nice if there were
a standard way to annotate exceptions, and if exceptions weren't quite so
inefficient - but it's much easier to design or learn an API when there's one
error-handling system consistently applied, instead of two independent ones.

