> On May 3, 2019, at 3:06 AM, Rowan Worth <row...@dug.com> wrote: > > But there's a very clear > convention set out surrounding the use of panic() - it should never form > part of a module's public API. It's not an error reporting mechanism and > callers should never be expected to invoke recover() just to use your > module.
At the risk of going farther OT… There’s precedent for this: consider what happens in Go if you access a nil reference. IIRC (I haven’t used Go much in a few years) it triggers a panic. So basically, the “.” operator has a sort of “assert(ref != nil)” in its implementation. Again IIRC, the same thing is true of the integer division operator when the denominator is zero. In neither case is this part of an API, it’s very literally a “panic” in the usual sense of the word: an escape from an intolerable situation. Exactly the same would be true of other situations where an assert() function could be used. Of course it shouldn’t be overused, but reserved for a situation where either (a) the flow of control would soon panic anyway at the language level due to a nil deref or something similar, and an explicit assertion failure just makes the failure easier to diagnose; or (b) continuing would have damaging effects like corrupting state. But I’ve learned not to question Go design decisions in their forums; it tends to lead to a lecture on why they’re right and I’m wrong. (One of the minor reasons I don’t use Go anymore.) —Jens _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
