This question already has an answer here:
- How to end C++ code 14 answers
I'm reading this question and there is an answer that explains why using exit() is bad because:
- You will end up having multiple exit points from the program
- It makes code more convoluted (like using goto)
- It cannot release memory allocated at runtime
I should clarify that I'm using Qt, so the code is already a bit "convoluted" since I'm taking advantage of signals and slots. That being said, for issue #1, I see it's related to #2, but my code currently attempts to avoid usage of exit() because I was told it would make my code look like a mess, but avoiding exit has made it a mess. I have functions that don't have to return anything, returning things. For example, when I have users register and their username already exists, instead of just calling exit() after telling the user registration has failed (which is the desired behavior in this situation) I return false to a function which then returns false to another function which then returns false to my main which then checks if that function returned true or false, and if it returns false then it returns 0. So much for avoiding exit() making the code clean.
For the third issue, doesn't using exit(0) tell the OS that the program is done running and the OS will free that memory by itself anyway? I ran a test case that uses exit(0) when I press a button and the process is removed from the process list and the memory is freed, so why is this even a concern? It seems it's an outright false statement, at least on Windows.
Just blindly calling exit() somewhere in your program is considered bad for a simple reason:
It does not properly shutdown other threads (they just get terminated), it does not properly flush all buffers (stdio files are flushed) and guarantee a consistent and valid state of permanent/shared resources (files/shared memory/other ways to communicate).
Still, if you can guarantee that no thread is running which might interfere (by being killed holding a lock or such), and all buffers which need it will be flushed by exit(), that's a valid way to achieve a faster shutdown.
Much modern software is programmed for even faster shutdown:
It is crash-tolerant, in that at nearly every time, just shutting down using e.g. _Exit() (not even calling atexit or at_quick_exit registered hooks) is ok. That is vastly faster than an ordered shutdown in most cases (Windows user interface resources should be destroyed first if possible, because they are an exception).
For further reading: Crash-only software (PDF!)
Crash-only programs crash safely and recover quickly. There is only one way to stop such software - by crashing it - and only one way to bring it up - by initiating recovery. Crash-only systems are built from crash-only components, and the use of transparent component-level retries hides intra-system component crashes from end users. In this paper we advocate a crash-only design for Internet systems, showing that it can lead to more reliable, predictable code and faster, more effective recovery. We present ideas on how to build such crash-only Internet services, taking successful techniques to their logical extreme.
Items 1 and 2, I disagree with. Those are more matters of style and preference.
As to item 3, you should look at the documentation to see what it actually will or will not free or flush (http://en.cppreference.com/w/cpp/utility/program/exit and http://msdn.microsoft.com/en-us/library/6wdz5232.aspx). For instance, the MS documentation says "flushes all file buffers before it terminates the process."
When your program exits, the OS will reclaim the memory, but that's not what he's talking about. What he means is that resources like semaphores won't be released properly or in a timely fashion. Maybe it's a concern, maybe not, depending on what sort of resources you're using.
来源：https://stackoverflow.com/questions/25141737/why-is-using-exit-considered-bad