4 ms·

Exceptions make it harder to reason about your code's execution path. If you raise an exception, it is often not obvious who in the call stack is ultimately goi

Exceptions make it harder to reason about your code's execution path. If you raise an exception, it is often not obvious who in the call stack is ultimately going to catch and handle it. The logic for that can live pretty much anywhere. This is not to mention the try/catch/finally pyramids you get from trying to cope with nested failure cases. Go uses a well-understood mechanism: return. Control reverts to the caller. It's simple, which was an explicit design goal of Go. IMHO, if you have a choice between exceptions or not, they just aren't worth the value they deliver. As Josh Bloch says, use them for exceptional circumstances only, to indicate truly exceptional circumstances, such as catastrophic errors. Re: refactoring: http://golang.org/cmd/gofmt/ http://golang.org/cmd/gofmt/. Check out the -r option. In practice, is this really a huge deal? Modulo go fmt, what editor doesn't support multi-file S&R with regex? Isn't this what a compiler is for? All in all, this sounds like bikeshedding about syntax. We're all entitled to our opinions but it's awfully hard to say anything interesting about syntax which has not already been said a bajillion times.

kaffiene 14y ago
Exceptions make it easier to modularise your code. Exceptions make it easier to treat a group of risky actions as a single transaction that either all work in result in one path on failure as opposed to checking absolutely everything that could fail. One of the few things I really hate about C is having to check return value after return value. It's tedious and makes for ugly code. You misunderstand Josh Bloch. He does not say to not use exceptions or that exceptions are bad, he says that you shouldn't use exceptions for expected occurances, hence "for exceptional circumstances". This is a code design criticism, not a language feature criticism.

kaffiene 14y ago

Exceptions make it easier to modularise your code. Exceptions make it easier to treat a group of risky actions as a single transaction that either all work in result in one path on failure as opposed to checking absolutely everything that could fail. One of the few things I really hate about C is having to check return value after return value. It's tedious and makes for ugly code. You misunderstand Josh Bloch. He does not say to not use exceptions or that exceptions are bad, he says that you shouldn't use exceptions for expected occurances, hence "for exceptional circumstances". This is a code design criticism, not a language feature criticism.