I'd suggest you expose both kind of APIs as in: * https://golang.org/pkg/regexp/#Compile * https://golang.org/pkg/regexp/#MustCompile
Implementing the `Must` flavor is trivial, just call the standard func and panic() if you get an error. As a side effect you'll get a unique point where to panic(), and callers will recognize it's likely yo panic() because the function has "Must" in its name. If in doubt, implement only the func that returns the error, the other is just syntaxic sugar IMHO. Example: https://golang.org/src/regexp/regexp.go?s=10768:10804#L298 panics() have been, in my Golang experience, a pain to deal with. Most of the time they are just below a "TODO refactor that sh*t" comment, or they would deserve that comment anyway. Proper error handling takes time, but it's an investment that pays of. My 2c. Christian. Le 07/01/2020 à 8:10 AM, Tay a écrit : > 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? -- Christian Mauduit __/\__ ___ uf...@ufoot.org \~ ~ / (`_ \ ___ https://ufoot.org /_o _\ \ \_/ _ \_ int q = (2 * b) || !(2 * b); \/ \___/ \__) -- 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/e7cd8115-bdb3-9edb-006b-1b5100e4cd7e%40ufoot.org.
