You shouldn't catch assertion failures.
Shortly, the idea behind the assert macro is that it checks conditions that
must be valid in the code. In other words, it catches something that CAN NOT
happen. For example, you have a non-NULL pointer to something, you check
that it is non-NULL, only you can call some function with this pointer and
it is vital for this function to receive non-NULL pointer. This function's
author can put assert in the function's code to enforce this condition. If
it is ever false, it must be a bug.
True, you can compile code with NDEBUG defined, and this usually wipes out
assert macro and other debugging stuff. So when you test, you compile
without NDEBUG and have the code that checks itself. When you ship your
code, you compile with NDEBUG and get slightly less secure version (but you
have tested it, haven't you ?), which lacks all these checks, so is much
Some library vendors also put asserts to check conditions that CAN NOT
happen with regular use of the library (but can happen if you don't use it
properly). Microsoft's ATL is an example. If this is the case, the library
is not inherently robust, and you have responsibility to learn the proper
use of the library.
From the other side, exceptions usually serve to detect real errors, i.e.
errors that CAN happen. However unlikely they are, but if they can happen,
assert should not be used to signalize them.
What about your case? You have assertion failures in the C library and you
want to get rid of them? Either this library is improperly used, and you
should then learn how to use it to avoid asserts. Or the library is buggy
NDEBUG and recompile the library and you won't have assertion failures. Bad