[burntsushi]

I hate to be rude, but I feel like you jumped into this thread without reading the context.

I'm not talking about panicing instead of returning errors. I'm talking about using an idiom---which is used in the Go standard library (see my link up-thread)---to make error handling more terse when you're working with code that is otherwise profligate with checking errors.

At no point is a panic exposed to the user of a program or to the client of a library. At no point are errors ignored. The panics are kept within package and converted to error values.

[redbad]

Guarding your library boundary with a recover doesn't absolve your library internals from being nonidiomatic by using panics. (That the stdlib uses panic/recover in a few specific places does not make it broadly idiomatic.)

Without seeing specific code I can't say for sure, but it's very unlikely that any database interaction code is best modeled with panic/recover for error handling. I'm very curious to see the source, at this point.

[burntsushi]

> Guarding your library boundary with a recover doesn't absolve your library internals from being nonidiomatic by using panics.

Using panic/recover doesn't automatically make your code nonidiomatic.

> (That the stdlib uses panic/recover in a few specific places does not make it broadly idiomatic.)

That the stdlib uses panic/recover in several places is a good indicator that "never use panic/recover" is bad advice. Note that while I agree that just because something is in the stdlib doesn't mean it's idiomatic, I also cite that this particular approach is used to make the structure and organization of code more clear. Since it's used in several packages, I claim that this is a strong hint that panic/recover is appropriate in limited scenarios.

> Without seeing specific code I can't say for sure, but it's very unlikely that any database interaction code is best modeled with panic/recover for error handling. I'm very curious to see the source, at this point.

It's really not that hard to imagine. For example: http://play.golang.org/p/fhpRLd8EHY

We seem to have some wires crossed. Let's be clear, shall we?

* The panic/recover idiom is rarely used, but it is an idiom.

* There are trade-offs involved with using panic/recover. In my sample linked in this comment, many of the functions in database/sql need to be stubbed out so that they panic. However, the cost of this is relatively small, since it can mostly be isolated in a package.

* The idiom is most frequently seen in parsing because there are a lot of error cases to handle and the response to each error is typically the same.

* While parsing is the common scenario, I claim it is not the only one. I cite that database work is profligate with error checking, and depending on your application, there's a reasonable chance that the response to each error is going to be the same. When doing a lot of it, it can pay off to use the panic/recover idiom with similar benefits as for doing it with parsing.

* There may well be other scenarios where such handling is appropriate, but I have not come across them.

I've done an unusual amount of work with parsers and have done some database work, so I've had the opportunity to bump up against the panic/recover idiom a bit more than normal. As with anything else, it can be abused. But I find it extraordinarily useful in certain situations.

[burntsushi]

I've fixed some compile errors in my code snippet: http://play.golang.org/p/PLyMAD5ZvG --- sorry about that.