Isaacs: try/catch is an anti-pattern
This seems to be exactly the attitude of Go:"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.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.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."http://golang.org/doc/go_faq.html#exceptionsIn Go, if there's a programmer error, call panic(); if there's a non-programmer error, return it as a second return value.[Added] Plus, it's obvious to see where people ignore errors:   f, _ := os.Open("filename")

"_" 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.   f, err := os.Open("filename")

If you don't use "err" later, this won't compile.   f, err := os.Open("filename")
   if err != nil {
      // handle error
   }

This code handles error.