[zeromq-dev] czmq: Error Traceability with assert(...) and release code

[Pieter Hintjens]

On Fri, Mar 7, 2014 at 3:13 PM, Christoph Zach <czach at rst-automation.de> wrote:

> To further use zyre/czmq We are planing on replacing all the assert(...) statements
> with actual error handling routines.

As Olaf explains, the asserts cannot ever happen in practice unless
there is a coding bug in your app or in CZMQ.

If you can reproduce an assert under "normal" conditions, that is a
bug that we take very seriously and fix.

Code that has hit an internal error _cannot_ continue to operate
sanely. The extensive use of asserts is a deliberate and long-standing
design choice, and though you may do what you like with your forks of
the codebase, such patches would be rejected without much pity.

I'd not trust a system that had asserts disabled. Production code (and
I've made that my profession for decades) should run with all asserts
enabled. The correct response to a internal failure is crash fast,
recover fast. You cannot run a software system reliably when you have
internal errors. Adding error handling to recover from (by definition)
unforeseen internal errors makes things less, not more reliable.

What can be helpful is to replace the assert() macro with a more
extensive error reporting system. However be careful you don't try to
do to much: the state of the application when it hits an assert is
unknown. You can have arbitrary memory corruption, for instance. Doing
*anything* more than "print error & exit" leaves you open to worse
damage.

-Pieter