Search code examples
c#debuggingassertionsassertionnanomsg

How to properly handle an "Assertion Failed" message

I'm using nanomsg to send / receive data between multiple components. Sometimes when I publish some data to another component I get an error:

"Assertion failed: ...".

I'm not too familiar with Assertion (this is my first time encountering them).

How does one properly handle an assertion?

This has happened during development AND on published Debug builds. With the Debug builds, the executable crashes.

Is there anyway to handle this cleanly?

Will this happen with a Release build?

This rarely happens - I've seen it occur about once out of every 70 publish attempts so it's not too easy to recreate and test.

Solution

  • DEFINITION:

    assert( int anIntValueTestedAndAbortCalledIfNonZERO )

       This can help programmers find bugs in their programs, or
   handle exceptional cases via a crash that will produce limited
   debugging output.

   If expression is false (i.e., compares equal to zero), assert()
   prints an error message to standard error and terminates the program
   by calling abort(3).  The error message includes the name of the file
   and function containing the assert() call, the source code line
   number of the call, and the text of the argument; something like:

    USE-CASES:

    Intentional abort()-s help debug the algorithmisation to properly meet & handle all possible values in the context of the processing.

    assert(   length > 0
      && "DEBUG: [length] must be positive"
          );                               /* PREVENTS ANY CALL
                                              WITH A DECLARED
                                              NEGATIVE SIZE
                                              FOR A BUFFERED STRING
                                              TO PROCEED & CRASH THE IO-DATAPUMP
                                              #3588502 / QA-CLOSED
                                              */

    Thus - yes, it may be in production release so as to still help ( safety-fuses ). Depends on compilation, with respect to DEBUG macro and options, used in version-release QA-process.

    The same practice is common not only in modules / libraries, but also in user-programmes ( application development ), where many languages support explicit syntax for this very behaviour, for the same purpose ( safety-fuses ). Actual syntax rules may vary language to language.

    Handling? Well, user-programmes do not "handle" assertions, but application designers are responsible for meeting the API assumed conditions ( like DIV!0 ~ one ought not divide by zero, so an attempt to do so will be legally abort()-ed, as such call violated the ( assumed ) rules ).