Re: assertions: does it matter that they are disabled in production?
In article <vjh6a4du1ivthu7ghj2tsvqlkjprf29utn@4ax.com>,
Geoff <geoff@invalid.invalid> wrote:
I don't say asserts shouldn't be used, I say they don't belong in released
code as they merely crash the program and there are many cases in my line
of work where this is not permissible and is downright irresponsible.
If you don't have faith that you have caught all the bugs and the
ASSERTs will never fire, why do you have faith that your recovery code
will solve the much harder problem of taking the program from an
unpredictable state into a legitimate sane state?
If your program (function) needs runtime checks of the data,
ASSERTs aren't for runtime checks of the data. They are to detect
programming errors.
Runtime data integrity failure in code released to customers should output
a meaningful diagnostic, either as a message to the user or written to a
log file for the user to send to your support team, not just an assertion
message.
How do you do that if you can no longer trust the state of your program?
I do use asserts, but I use them to catch errors in debug/test before
releasing the code to customers. I also have runtime checks in place for
cases where bad data must not cause the function to fail and appropriate
handling is going to be performed in debug and release mode code. This is
why functions have error returns and why programmers always check them, is
it not?
Bad input is not a programming error. ASSERTs are for catching
programming errors.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> 773 961-1620
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]