Re: assertions: does it matter that they are disabled in production?
On 2008-08-07 12:55, Phil Hobbs wrote:
Erik Wikstr???m wrote:
The alternative is to either continue with faulty data (which is *much*
worse than abort()), or to throw an exception which you catch in main()
and terminate the application there.
That's an over-generalization--not all faulty data is a fatal error. Do
you really have to call abort() and destroy the user's work just because
you can't open a logfile or you have a zero-length string in a dialog
box? Puh-*leeze*.
You misunderstood, I was talking about how to deal with errors that can
not be handled gracefully. In which case terminating is the only solution.
Unless you can generate a stack-
trace or get some other useful information that way it does not buy you
anything you would not get from normal assert(), except a bit more
complicated code.
I generally use a modified assert() that causes a divide-by-zero FPE, so
that any time an assertion fires the program drops into the debugger
conveniently. This obviously isn't a replacement for careful coding,
but it doesn't take too many bugchases avoided to repay the small
additional effort.
I was talking about production-code, where you want to output
informative text which can help you locate the error and fix it. But I
don't think that dropping into a debugger (if one exist on the
production environment) is appreciated by the customers.
--
Erik Wikstr??m
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]