Speaking as someone who is probably to blame for a significant proliferation of public facing panics, that example is probably not a good place for it.
There are uses in the standard library of public facing panics, but they generally fall into the categories of simulating the type system (in reflect), or compiler-time known things that should never fail (in text/template and html/template where the commonly used functions return an error and a conversion "must" function convert a non-nil error to a panic. On Mon, 2020-01-06 at 23:10 -0800, Tay wrote: > Hi, > > Just a quick question. I know it's well accepted that panics leaking > to the > public API of a library is generally a no-go. > > Yet, are there any exception to the rule? > > For instance, I have a library that instantiates some database > prepared > statements (so, the majority of the elements are instantiated and > used in > the main function). I would like to panic instead of returning an > error > because, if db.Prepare(q) returns an error, there is no point in > continuing, the error is barely recoverable. Besides, it will allow > for a > better looking API so to speak. > > Any comments? > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/f88ad3db55eef52ad03805a15fe7020d1b823678.camel%40kortschak.io.