4 ms·
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. D
by hermitdev 7y ago
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
- catlifeonmars 7y 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 7y 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 7y agoYou can also easily enable runtime failures so the point is indeed moot.