[luriel]

Anyone using panic/recover across API boundaries to emulate exceptions should have their brains gofmt-d.

But so far I have not noticed anyone doing this, perhaps because actually returning and handling errors properly is not as much of an issue as most people make it to be.

[jlgreco]

I personally like Go's error handling so I wouldn't consider doing it, but what exactly would be the issue with doing so?

The reasons not to that I have seen are all basically boil down to "Because you're not supposed to, it's not what it's for". Because of how recover works it certainly wouldn't make sense to use it exactly the same as try/catch is generally used, but what exactly would be the problem with using panic/recover for more common cases (less 'exceptional' cases...) if we've already decided to not value writing idiomatic code?

It strikes me as a terrible idea, but try/catch does too.. I guess I don't understand why it would be even worse than that.

[luriel]

Because one of the nice things about Go is that I don't have to worry about this.

Is not just unidiomatic code in itself, but it creates unidiomatic APIs that behave in ways Go programmers don't usually have to worry about.

Unlike Python programmers, who should always be worrying about what exceptions any function or method they call could throw, hell, even setting a property or adding an item to a map or list can throw all kinds of exceptions. And this is rarely documented, and when it is documented it is usually incomplete, because whoever wrote that code doesn't know what exceptions might be thrown by any other code he calls.

[jlgreco]

Well right, I get all of that.

Just to be clear though, there is no point "adding" exceptions to Go because the functionality is already there, just named something else and meant to be used in a completely different way?