Many thanks everyone for the insight. Instead of accepting a raw query string and try to compile it, I will defer that part to the library user. So, I will simply accept a *sql.Stmt. That way, I won't have to handle the various failure modes within the library and leave the issue to the end user. Thanks again,
On Tuesday, January 7, 2020 at 2:10:32 PM UTC+1, Brian Candler wrote: > > On Tuesday, 7 January 2020 07:47:28 UTC, Axel Wagner wrote: >> >> Personally, I consider panics "run-time type-errors". That is, they >> indicate a bug that couldn't be caught statically by the type-system - so >> the program shouldn't have compiled in the first place and crashing it is >> the right choice. Dereferencing a nil-pointer or indexing out-of-bounds >> fall into that category. So does using reflect to do otherwise invalid >> operations (which is why reflect panics). IMO, a straight-out rejection of >> panics doesn't make sense, unless you assume your type-system is perfect >> and so there are no bug-free programs. >> >> Another way to look at it, is that a panic in general dumps a >> stack-trace, while an error is being presented to the human using the >> resulting software. And that stack-traces in general are not actionable to >> the user of a software, but only its developer - while error message don't >> contain the necessary details to debug a program, but can (should!) provide >> actionable advise to its user. Thus, panics are the right tool to use when >> reporting an issue that requires programmer attention and errors are the >> right tool when reporting an issue that requires user-attention (or, of >> course, can be handled programmatically).¹ >> > > Or to put it another way: if the caller of your function violates your > *API contract* then panic. The bug is with the caller for not invoking > your function properly, and therefore the calling code needs to be fixed. > > By that definition: if the API contract says "you must pass in a valid SQL > statement", and you can say with 100% certainty that the SQL they passed in > is invalid, then by all means panic. But if you can't be sure of that - > e.g. the problem could be a failure to connect to the database - then > return an error. > -- 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/77510edd-7662-4f93-80a4-f5742e904e5c%40googlegroups.com.
