Menu
I'm reading this question and there is an answer that explains why using exit() is bad because:
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.
988
2 Though structured programming was my approach for many years, in the last few have switched to entirely using explicit exits at first possible opportunity. This makes faster execution and almost eliminates logic errors that used to result in endless loops (hanging). – DocSalvager
This makes some sense if your function is long, and if you have multiple nested loops. However, your functions should be short, and you should wrap loops and their bodies into short functions of their own. Generally, forcing a function to have a single exit point can result in very convoluted logic.
Using break and continue frequently makes code hard to follow. But if replacing them makes the code even harder to follow, then that's a bad change. The example you gave is definitely a situation where the breaks and continues should be replaced with something more elegant. Share Improve this answer
But use of statements like breakand continueare absolutely necessary these days and not considered as bad programming practice at all. And also not that difficult to understand the control flow in use of breakand continue. In constructs like switchthe breakstatement is absolutely necessary. Share Improve this answer
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.
67
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
