It seemed random and out of place to me. Like some sort of Wiki vandalism.

Why do I care about their opinion of Go in SQLite dev docs?

Whoever wrote that was probably shooting from the Hipp.

> Why do I care about their opinion of Go in SQLite dev docs?

Apparently some peoplr care, considering the number of comments on how Go can, does and should handle this usecase.

I did not understand this comment, as they also wrote ALWAYS, NEVER and testcase. Why could you not write your own assert in Go? (I have not programmed in Go)

I dunno either, because it's incredibly trivial.

    func assert(cond bool){
      if !cond {
        panic("whoopsies")
       }
    }

And then you can just #define assert(...) to eliminate it...oh wait, Go doesn't have a macro-preprocessor.

To play along....

Go does have build tags, so one could have 2 files for the assert function, each with opposite build tag logic. It does allow for an effective NOP (it would be a stub function and I believe the compiler would eliminate that).

I tested this and it does indeed eliminate that code.

I'm wondering if it inlines it (and thus eliminates it).

But this would come with a performance penalty: it makes the function you assert() in no longer a leaf function (it calls assert()) and AFAIK, Go only inlines leaf functions. (So, any function in which you call assert() is no longer eligible for inlining.)

chrchang523 is correct. In my test the caller function can still get inlined.

deathanatos: Go 1.12 can inline non-leaf functions, and I’d be surprised if it still fails to do the right thing here.

It would still evaluate the condition in both cases, unless it can guarantee that the condition is a pure function with no observable side effects.

You can always log to stderr with a stack trace and exit with a non zero static code. I’m guessing they’re referring to the fact that the built in panic keyword can be “caught” further up the stack a la an exception.

IMO, far better to log, then abort/core. I want to be able to inspect the state of the failed case, not just know that it failed.

It’s far better to let the caller decide. As a user of a library, I absolutely do not want a library terminating my process. Sure, some programs can benefit from this, but some programs need to guarantee that they keep running. Being able to recover (Go’s counterpart to panic()) allows the caller to decide which behavior they want.

I'm not sure I agree. There's a very, very small limited set of conditions that a client can recover from a condition that would trigger an assertion failure. Dont want an abort? Then use the release libs where those have been preprocesed out.

Conversely, at a former employer we used a set of 3rd party database libs for ODBC on Linux that for the smallest config error would emit nothing to stderr and call exit(1) from a shared lib. that was beyond annoying

I was afraid someone would mention preprocessing out the asserts :)

That also has its advantages, but would argue that it is impossible to selectively opt in or out.

Honestly, for a well tested piece of code, the point is moot, since the assert(s) will never evaluate false anyway.

> I was afraid someone would mention preprocessing out the asserts :)

Problem is, you need to understand what you're using, and like it or not, assert is defined as a macro by the C standard. And, assert is conditionally defined (and it's not the only conditionally defined macro).

I know its long, verbose, and dry; but if you want to understand C (or C++ for that matter), you really need to read the ISO standards that correspond to the implantation.

You can also easily enable runtime failures so the point is indeed moot.

If you're in the same process as the code that had its invariant fail, how can you ensure that your process is in a safe state afterwards? A failed invariant, by definition, means that you're in uncharted territory - any anticipated failures are (assuming proper design) reported via the usual error mechanisms.

To draw_down: your comments are showing up as dead,

As for assert in Go... couldn't you just make a function that takes a Boolean and panics?

You could, but then when you get an error, you'll see the file and line number of the assert function rather than the code that actually produced the error.

The runtime package allows you to grab the current trace, you can just pop the last frame off and print that.

True. The only other challenge is that in production software you rarely want to call panic()

As another comment mentioned you can just use build tags to make assert a no-op in release builds

Also, there is no way to eliminate the assert clause in a high-performance (release) build.