What's the difference between those three, and how shall I end program in case of exception which I can't handle properly?
-
4This is not a duplicate, but rather, a subset with some good answers http://stackoverflow.com/questions/397075/what-is-the-difference-between-exit-and-abort and it was tagged C++ too! – Ellie Kesselman Jan 08 '12 at 07:49
-
`std::abort` is reasonable if an exception cannot be resolved in a destructor. – Daniel Feb 14 '15 at 15:10
-
1For more information about `std::terminate` see these articles in Andrzej's excellent C++ blog: https://akrzemi1.wordpress.com/2011/09/28/who-calls-stdterminate , https://akrzemi1.wordpress.com/2011/10/05/using-stdterminate/ – Ohad Schneider Nov 28 '16 at 14:57
6 Answers
abort indicates "abnormal" end to the program, and raises the the POSIX signal SIGABRT, which means that any handler that you have registered for that signal will be invoked, although the program will still terminate afterwords in either case. Usually you would use
abort
in a C program to exit from an unexpected error case where the error is likely to be a bug in the program, rather than something like bad input or a network failure. For example, you mightabort
if a data structure was found to have a NULL pointer in it when that should logically never happen.exit indicates a "normal" end to the program, although this may still indicate a failure (but not a bug). In other words, you might
exit
with an error code if the user gave input that could not be parsed, or a file could not be read. An exit code of 0 indicates success.exit
also optionally calls handlers before it ends the program. These are registered with theatexit
andon_exit
functions.std::terminate is what is automatically called in a C++ program when there is an unhandled exception. This is essentially the C++ equivalent to
abort
, assuming that you are reporting all your exceptional errors by means of throwing exceptions. This calls a handler that is set by thestd::set_terminate
function, which by default simply callsabort
.
In C++, you usually want to avoid calling abort
or exit
on error, since you're better off throwing an exception and letting code further up the call stack decide whether or not ending the program is appropriate. Whether or not you use exit
for success is a matter of circumstance - whether or not it makes sense to end the program somewhere other than the return statement in main
.
std::terminate
should be considered a last-ditch error reporting tool, even in C++. The problem with std::terminate
is that the terminate handler does not have access to the exception that went unhandled, so there's no way to tell what it was. You're usually much better off wrapping the entirety of main in a try { } catch (std::exception& ex) { }
block. At least then you can report more information about exceptions that derived from std::exception
(although of course exceptions that do not derive from std::exception
would still end up unhandled).
Wrapping the body of main
in try { } catch(...) { }
isn't much better than setting a terminate handler, because again you have no access to the exception in question. There is at least one benefit, though: whether stack unwinding is done when an exception goes completely uncaught is implementation defined, so if you need guaranteed stack unwinding, this would be a way to get that.

- 20,030
- 7
- 43
- 238

- 74,820
- 18
- 121
- 166
-
14Can you update this answer with C++11 info? It seems that there is now ways to get the exception in the catch(...) and in the terminate handler. – Klaim Jul 31 '12 at 16:02
-
4In C++ the terminate handler *does* have access to the exception through `std::current_exception()`. See example here: https://akrzemi1.wordpress.com/2011/10/05/using-stdterminate/ – anorm Jun 19 '17 at 08:34
-
Doesn't matter that you can get the current exception, since you can't inspect it. All you can do is re-throw it. – seattlecpp Sep 15 '17 at 20:12
-
5@seattlecpp you can rethrow it and catch a reference to it, which you can then inspect – gpeche May 20 '18 at 00:41
std::abort and std::exit (and more: std::_Exit, std::quick_exit) are just lower level functions. You use them to tell the program what you want it to do exactly: what destructors (and if) to call, what other clean-up functions to call, what value to return, etc.
std::terminate is a higher level abstraction: it is called (by either run-time or you) to indicate that an error in the program occurred and that for some reason it is not possible to handle by throwing an exception. The necessity for that typically occurs when error occurs in the exception mechanism itself, but you can use it any time when you do not want your program to continue beyond the given error. I compiled the full list of situations when std::terminate is called in my post. It is not specified what std::terminate does, because you are in control of it. You can configure the behavior by registering any functions. The limitations you have are that the function cannot return back to the error site and it cannot exit via an exception, but technically you can even start your message pump inside. For the list of useful things that you can do inside, see my other post.
In particular, note that std::terminate is considered an exception handler in contexts where std::terminate is called due to a thrown exception that could not be handled, and you can check what the exception was and inspect it by using C++11 using std::rethrow_exception and std::current_exception. It is all in my post.

- 5,027
- 27
- 36
-
Is it advisable to have a cleanup handler in case program terminates because of system signals? For example, invalid memory access leads to generation of SIGSEGV signal. In this case, is it good to just let the program to terminate and have the core file or register a signal handler to do the cleanup?? Are there any concerns of doing cleanup while handling system signals compared to doing a cleanup while handling std::terminate? – karthiksatyanarayana May 23 '19 at 12:24
If your program is multi-threaded, then calling exit()
will most likely result in a crash because global/static std::thread
objects will be attempted to destruct without exiting their threads.
If you want to return an error code and exit the program (more or less) normally, call quick_exit()
in multi-threaded programs.
For abnormal termination (without a possibility for you to specify the error code), abort()
or std::terminate()
can be called.
Note: quick_exit() has not been supported by MSVC++ until version 2015 .

- 13,865
- 7
- 86
- 158
-
This makes sense. However, calling the dtor of an unjoined thread will call std::terminate, so the program will not necessarily "crash". I think the standard does this because it can't throw in a dtor. Therefore in multit-hreaded programs it seems to me that std::terminate is the preferred method in ctors/dtors and std::quick_exit elsewhere. Please acknowledge... – Andreas Spindler Dec 07 '21 at 17:13
terminate() is automatically called when an exception occurs that cannot be handled. By default, terminate() calls abort(). You can set a custom handle with set_terminate() function.
abort() sends the SIGABRT signal.
exit() is not necessarily a bad thing. It successfully exits the application, and calls atexit() functions in LIFO order. I don't normally see this in C++ applications, however, I do see it in many unix based applications where it sends an exit code at the end. Usually a exit(0) indicates a successful run of the application.

- 16,230
- 17
- 74
- 137

- 878
- 6
- 5
-
8Unsuccessful! In both Unix and DOS, exit(0) indicates success and any other value passed to exit() indicates failure, not the other way around! – Richard Barrell May 15 '10 at 23:35
-
And also note that there are some historical systems where the success value is not zero. Prefer `EXIT_SUCCESS` instead of zero, at least for code readability. – jiwopene Nov 21 '22 at 13:19
- terminate leaves you the possibility to register what will happen when it is called. Should be one of the other two.
- exit is a normal exit allowing to specify an exit status. Handlers registered by at_exit() are run
- abort is an abnormal exit. The only thing which is ran is the signal handler for SIGABRT.

- 51,233
- 8
- 91
- 143
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
}
}

- 15,171
- 8
- 38
- 76
-
Huh. I had to try this out myself to verify, but you're right that stack unwinding does not necessarily take place for an uncaught exception. I find that surprising. – Tyler McHenry May 12 '10 at 15:54
-
8@Neil: Agreed basically, but exceptions that the program can't handle should be reported & rethrown. Let the app crash. – John Dibling May 12 '10 at 16:27
-
14To make sure the stack unwinds you should always catch in main. But I would re-throw from the catch. As some OS have the ability to automatically invoke debugging infrastructure if you have compiled in debug. – Martin York May 12 '10 at 19:15
-
5Exceptions that aren't caught even by a top-level handler could invoke a system reporting facility that dumps the process and uploads the exception report for the developers' attention, like Windows Error Reporting, Mac OS X error reports and iPhone application error logs. – JBRWilkinson May 14 '10 at 09:42
-
6@John The reason why it is surprising to me is that, although it makes perfect sense in light of how exceptions are actually implemented, it breaks the abstraction that an exception "propagates up the stack" until a suitable handler is found (or terminate is called). And leaky abstractions, while often unavoidable, are necessarily surprising when encountered. – Tyler McHenry May 14 '10 at 14:29
-
5Down voted because if you are aborting, you don't want unwinding, as the process may already be toast. – Bruno Martinez Jun 13 '13 at 16:06
-
19-1 because this doesn't answer half the question. "What's the difference between [abort, terminate or exit?]" This is a better answer: http://stackoverflow.com/a/397081/353094 Also http://stackoverflow.com/a/2820407/353094 is a great answer. – leetNightshade Jan 26 '15 at 17:50
-
3This is not a great answer. Although exceptions should be addressed as well, it's wrong to tell some to disregard the other 3 things they asked about. Especially, when the author explicitly stated it's an exception they can't handle properly. Exceptions are not the answer in this case. – Trevor Hickey Dec 14 '15 at 13:47
-
4I also downvoted. Although the solution may be valid and good, it does not address the big part of the quesiton, that is, the difference among the three. – bartgol Apr 04 '17 at 19:45
-
1I down-voted because these are useful during the debugging phase of a program. Sometimes you want to fail fast and you don't want the stack to unwind. Other times you simply don't want to use exceptions. – Galik Jul 21 '17 at 12:44
-
If a process is terminating because of an unhandled exception, trying clean up before exiting the process is bad advice. Let the process die. In the best case you lose information in the calling environment, in the worst case the attempt to clean up hangs and the process doesn't exit. – janm Dec 11 '18 at 11:01