Differencebetween Exit() and Abort()

What is the difference between exit and abort?

"Exit, Exit! Abort, Raise…Get Me Outta Here!" describes everything you'd want to know I think.

In short:

  • Kernel.exit(code) "exits" the script immediately and returns the code to the OS, however, just before doing it, it calls any registered at_exit handler that your code could have registered.
  • Kernel.exit!(code) does the same, but exits immediatelly, no at_exit handlers called.
  • Kernel.abort(message) takes a message that will be printed to STDERR just before exiting with a failure code=1.

Different values of exit codes are barely suitable for detecting problems and debugging the code. However, they are very simple to use and making the parent process read them is almost trivial. Hence, exit and exit!.

If you can spend more time and make the error checking more robust, you'll need some serious error messages, not just codes. Traditionally, you can print them to STDERR if it exists. You can print manually to STDERR via normal puts, but exit-codes will still be used at the lowest level.

Printing to STDERR does not mark your job automatically as failed, so, abort was created to allow you to write and quit easily. A default exit code of 1 is enough to mark the FAIL condition, as it's assumed that all the real contextual information will be included in the error messages provided by you.

Also note that any unhanded exceptions, such as raise "wtf" with no rescue anywhere, actually behave as if calling Kernel.abort: they print to STDERR and use exitcode=1.

You said exit(false) but the exit! documentation says that the parameter is status code to be used.

I've just checked that on Windows and Ruby 1.9.3:

exit 0       # quits with code: 0
exit 1 # quits with code: 1
exit false # quits with code: 1
exit true # quits with code: 0

which really surprises me, as I'd assume that false would be coerced to 0 in the traditional C way. So, maybe you should rather be using integers like 0 or 1 to be perfectly clear about what code will be used.

When abort() is preferred over exit()?

Using abort will dump core, if the user has core dumps enabled. So as a rule of thumb, I'd use abort if you're so unsure about what's gone wrong that the only way to get useful information about it is by analysing a core dump.

If you can safely exit from any given point, and don't need the core dump, then exit is a nicer approach.

What's the difference between abort() and exit() in Node?

process.abort() stops the process immediately.

process.exit([exitCode]) method instructs Node.js to terminate the process as quickly as possible. You can also specify an exit code.

For exit codes:

  • 0 means the process was exited successfully.
  • 1 means it ended abnormally.
  • When omitted, 0 is the default value.

abort, terminate or exit?

My advice would be not to use any of them. Instead, catch the exceptions you can't handle in main() and simply return from there. This means that you are guaranteed that stack unwinding happens correctly and all destructors are called. In other words:

int main() {
try {
// your stuff
}
catch( ... ) {
return 1; // or whatever
}
}

Is it ok to use exit(1) to abort the program or should you attempt to return 1 from the main()?

It's a choice to make for yourself.

If you're writing a library, you really ought to report failure to the caller, which may be able to recover in ways you can't internally, and which might need to perform other cleanup that's not done by registered atexit() handlers.

If your code might be called from C++ or other high-level languages, then again, don't unilaterally exit, as that prevents destructors running to perform similar cleanup.

When you check memory use using Valgrind, then exit() will leave lots of objects in the "still accessible" state, making it harder to find your real leaks.

So I generally recommend returning from main(), but would tolerate some use of exit() in program-specific code that's never going to end up in a library.

What is the difference between std::quick_exit and std::abort and why was std::quick_exit needed?

There's a good write-up available here, I'll just summarize it. This feature was added to specifically deal with the difficulty of ending a program cleanly when you use threads. By nature, the exit is started by a highly asynchronous event, the user closing the user interface, the admin shutting down the machine, etcetera. This happens without regard to the state of the threads the program started, they are almost always in a highly unpredictable state.

In an ideal world, the program's main() function asks the threads to exit, typically by signaling an event, waits for the threads to end and then exits main() for a clean shutdown through exit(). That ideal is however very hard to achieve. A thread could be buried deep inside a system call, say, waiting for some I/O to complete. Or it is blocking on a synchronization object that needs to be signaled by another thread in the right order. The outcome is rarely pleasant, real programs often deadlock on exit. Or crash when the shutdown order is unexpected.

There's a simple and very tempting workaround for this problem: call _exit() instead. Kaboom, program ended, the operating system brooms up the shrapnel. But clearly without any cleanup at all, very messy sometimes with artifacts like a half-written file or an incomplete dbase transaction.

std::quick_exit() offers the alternative. Similar to _exit() but with still the option to execute some code, whatever was registered with at_quick_exit.

Difference between exit and kill in C++

Difference between exit and kill in C++

One difference is that kill function is not specified in the C++ standard library. It is merely specified in POSIX. exit is standard C++.

Another difference is that kill(getpid(), SIGKILL) will cause the operating system terminates the process forcefully. exit instead performs cleanup (by calling a atexit callback, and flushing streams etc.) and terminates the execution voluntarily.

So, which of the following code is better, or should I use them both?

Depends on the use case, but usually exit is more sensible, since one usually wants the cleanup that it provides.



Related Topics



Leave a reply



Submit