> try/catch is significantly more verbose than just if err != nil // do something imo...
Further to what the other replier said (about the ability to bubble-up errors), try-catch also lets you handle multiple errors in one block:
```
try {
fileOutput1 = getSomethingFromFileSystem()
fileOutput2 = getSomethingElseFromFileSystem()
fileOutput3 = ...
} catch (FileSystemException e) {
// handle
}
```
If I understand it correctly, GoLang's idiom would claim that this is a bad thing to do, and each error should be handled individually. Which - sure! That's _usually_ a reasonable, defensible, and safe position. But that means that GoLang's approach is always as verbose as its possible to be, whereas try/catch at least has the _possibility_ to condense handling.
> ...and also much more brittle
Can you be specific about what you mean by "brittle"? To me, it denotes a lack of flexibility - that is, if thing1 changes in an unexpected-but-still-legal way, then thing2 is likely to break. I can't see how that applies to try/catch-vs err-check - in both cases:
* The exception/error is bound to a variable
* (in most well-typed languages) the Type of the exception is checked by the type system, and/or (in every language, inc. GoLang) properties of the exception are checked by code
* Something is done (a standard code action, a return/throw of an exception, or a program termination)
You can write a brittle GoLang check (only checking for, say, `if e.message = "a very specific error message"`), and you can write a very flexible try/catch block (with a fallback `catch (Exception e) {doSomethingGeneric()}` - or, indeed, the _most_ flexible "try-catch" is "don't even catch it, let it bubble-up and let your framework/application handle it")