Those are good guidelines. I'd like to add a couple of nuances.
For “system” or “operations” errors (we have a database engine that
executes in the address space of processes, so there can be errors such as
an IO error or an inability to expand because of insufficient space in the
file systems)
On Tuesday, January 7, 2020 at 12:47:28 AM UTC-7, Axel Wagner wrote:
>
> 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
> progr
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.
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
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()
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 refl
On Tue, Jan 7, 2020 at 8:10 AM 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.
>
Not *that* well accepted :) I tend to disagree. But maybe I'm simply in a
vanishingly small minority.
Yet, are there
Panic is for unrecoverable errors. If that query is provided by the user, then
return an error.
If it is part of your library, and cannot be wrong, then panic.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and st
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 insta
