Re: CFile and FILE*
On Thu, 27 Mar 2008 14:49:18 -0500, Joseph M. Newcomer
<newcomer@flounder.com> wrote:
If the file state were the only state, perhaps. But exiting a program with hundreds of
items on the stack, some of which may be important, is extremely risky. I developed a
severe aversion to it when the dbx debugger kept crashing, because every time there was
"something wrong" the programmer just called "exit", taking the debugger and my entire
debug session with it. It had over 300 exit calls, and we had to fix them so the debugger
would not exit if it became confused. (dbx was BQS: Berkeley Quality Software--written
late at night, tested on one case, and put on the release tape).
Sounds like dbx was crap. (I only remember "dbx" from the old magnetic
audio tape days. ISTR it was regarded as superior to Dolby, but I never
used it.)
While exit() may flush the buffers, it does not guarantee that the data thus flushed
results in file integrity; it may have been only partially-constructed when the exit() was
called, so the file is now meaningless.
In the situation I'm talking about, there's no difference between calling
exit() and tediously propagating return codes all the way back to main.
I can't imagine why any program would want to call it. It guarantees that some state,
somewhere, is not being properly updated. The absolutely worst example of this was a
Windows database library I used in the early 1990s, which would issue unintelligible
MessageBox notifications, to the NULL parent, then when the OK button was clicked, exit
the program. It was one of the most irresponsible examples of fifth-rate programming I'd
ever had the misfortune to use. We eventually changed to another database package because
it was too hard to fix the one we had (it came with source code, but the coding was so
poor that it was nearly impossible to figure out how to fix the problem, let alone fix
it!)
joe
The solution to all your admonitions is simply not to use exit()
incorrectly. When it's used correctly, in appropriate situations, such as
the typical console program, it's safe, effective, and easier than anything
else. I already talked about using exceptions to get the stack unwinding
and object destruction you mentioned, but that's for C++. In C, you're left
with propagating return codes, which is unreliable, verbose, and tedious,
or, horror of horrors, setjmp/longjmp. I wouldn't inflict that on anyone
when it's possible to use exit(), e.g. to report an illegal command line
option. Again, I'm talking about using exit() correctly in appropriate
situations. The one situation I've talked about is console programs such as
grep. I fully agree there are many ways to misuse it, many more than there
are correct ways, and your dbx and database examples certainly represent
incorrect usage. I would never use it in a C++ program that uses exceptions
or even has local objects with destructors, which is why I said, "In a more
complex C++ console program, I can see preferring exceptions to exit() and
indeed I've done just that." What I don't agree with is the statement that
exit() must not be used even in console programs, where it's often
acceptable. Anyway, $.02, FWIW. :)
--
Doug Harrison
Visual C++ MVP