4 ms·
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)
by rileymat2 8y ago
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)
- drb91 8y agoYou 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.
- hermitdev 8y agoIMO, 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.
- catlifeonmars 8y agoIt’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.
- hermitdev 8y agoI'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
- catlifeonmars 8y agoI 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.
- hermitdev 8y ago> 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.
- drb91 8y agoYou can also easily enable runtime failures so the point is indeed moot.
- int_19h 8y agoIf 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.
- fwip 8y agoI dunno either, because it's incredibly trivial. func assert(cond bool){ if !cond { panic("whoopsies") } }
- rabidrat 8y agoAnd then you can just #define assert(...) to eliminate it...oh wait, Go doesn't have a macro-preprocessor.
- pstuart 8y agoTo 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).
- helper 8y agoI tested this and it does indeed eliminate that code.
- deathanatos 8y agoI'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.)
- helper 8y agochrchang523 is correct. In my test the caller function can still get inlined.
- chrchang523 8y agodeathanatos: Go 1.12 can inline non-leaf functions, and I’d be surprised if it still fails to do the right thing here.