[betaclass]

With exceptions you can: a) handle the exceptions higher up the call stack b) consolidate error handling code for multiple error generation points

With Go you pretty much have to attach a conditional to many calls.

Your obsession with clean revision histories is another matter.

[nknighthb]

panic/recover substitute for most reasonable exception use cases.

[tptacek]

Using panic for non-fatal errors is non-idiomatic, isn't it?

[jlgreco]

Yeah, but arguably not as non-idiomatic as letting panics cross package boundaries. So long as you keep it all in your package I don't imagine very many people will mind if you use them a tad liberally (use them for things that are not truly exceptional).

I think most people who are bothered by Go's error handling are really just bothered by cross-package panics not being idiomatic (and thank god they aren't).

[nknighthb]

Define "fatal". Go-the-language and the standard library sometimes panic in situations that are bad but non-fatal for a long-running server process.

I have no issue with an argument that a panic making it out of a library meant for general external use is usually a bad thing -- that's not a "reasonable use of exceptions".

But my own applications are deliberately structured so that most of the outer layers can safely assume most operations will just work, as inner layers, to which interaction with external libraries is largely confined, will log.Panic() if they don't. It's the right choice 90% or more of the time, and leaves us with shorter, cleaner code.

In any case, I severely dislike arguments based on whether something is "idiomatic" or not. It's one thing when you're talking about loops and switches, and something else entirely when you hit someone over the head with it on architectural matters, especially in a language this young.