Isaacs: try/catch is an anti-pattern
This seems to be exactly the attitude of Go:<p>"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.<p>Go takes a different approach. For plain error handling, Go's multi-value returns make it easy to report an error without overloading the return value. A canonical error type, coupled with Go's other features, makes error handling pleasant but quite different from that in other languages.<p>Go also has a couple of built-in functions to signal and recover from truly exceptional conditions. The recovery mechanism is executed only as part of a function's state being torn down after an error, which is sufficient to handle catastrophe but requires no extra control structures and, when used well, can result in clean error-handling code."<p><a href="http://golang.org/doc/go_faq.html#exceptions" rel="nofollow">http://golang.org/doc/go_faq.html#exceptions</a><p>In Go, if there's a programmer error, call panic(); if there's a non-programmer error, return it as a second return value.<p>[Added] Plus, it's obvious to see where people ignore errors:<p><pre><code>   f, _ := os.Open("filename")
</code></pre>
"_" is a throw-away variable to indicate that this value won't be used in the code. It's obvious that the programmer decided to ignore the error.<p><pre><code>   f, err := os.Open("filename")
</code></pre>
If you don't use "err" later, this won't compile.<p><pre><code>   f, err := os.Open("filename")
   if err != nil {
      // handle error
   }
</code></pre>
This code handles error.