I know the differences between the two. One notable thing is that abort() sends SIGABRT signal, so it may be relevant when your software relies on them. But for a typical application exit() seems to be more safe version of abort()...? Are there any other concerns to use abort() instead of exit()?
+4
A:
Sometimes your program breaks to such extent that its state becomes inconsistent and so exit() will not work because it would cause global objects destruction and the latter would not function properly when the state is inconsistent. In such situations abort() is to be preferred.
sharptooth
2010-09-09 11:53:46
I suppose it's for example when IO becomes unoperational due to hdd failure? You catch this as an exception but you can't destroy file objects because their destructors need to perform file close. Thanks for the idea.
doc
2010-09-09 12:00:02
@doc: Yes, but it's a rather extreme example. A more C++ example: you're already handling an error and another error happens (not related to error handling process) and the handling code is reentered. That's not very good - errors happen faster that you can handle them. So you maintain a flag "I'm inside handling this kind of error already". Once code is reentered you throw in the towel - call `abort()` to terminate the program immediately.
sharptooth
2010-09-09 12:04:21
+12
A:
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.
Andy Mortimer
2010-09-09 11:56:09
I would rephrase that as: are you expecting your users to analyze core dumps? If not, don't use abort. (Keeping in mind that although you the developer might want a core dump, your users might not. So perhaps abort should only be used in a "debug" version of your executable.)
Ken Simon
2010-09-09 12:44:38
@Ken Simon: If users don't want core dumps, they can turn them off (ulimit -c 0). I think Ubuntu does that by default.
camh
2010-09-09 13:12:28
@camh: I would agree with Ken on this. when you send software in the wild you can't always control what system parameters users will choose. What if as a software developper you never want users to get core dumps ?
kriss
2010-09-09 14:11:44
@Ken, @kriss: I'd want my users to get core dumps, so they can include them in bug reports. If they don't want to do that, they can easily suppress them.
Mike Seymour
2010-09-09 15:42:20
@kriss as a developer, I think you can use setrlimit to disable core dumps for your process and child processes. That said, I'm with Mike Seymour -- I'd want to leave the option to the user. Most dists/users will disable them by default, so it's only interested people who'll get the dumps.
Andy Mortimer
2010-09-09 15:59:08
@Andy Mortimer: Yes, you can use setrlimit, but that is even *less* standard than say _exit(). My point is that I believe abort() is for bugs, the same kind of use cases than assert() (calling abort() is what the assert macro does and is probably the most common use of it). Just remember that when NDEBUG is defined assert generate no code. Depending on the kind of customer you may or may not want to hide bugs.
kriss
2010-09-09 16:33:49
+6
A:
Use abort() if your program is in a possibly corrupt state and you consider it too dangerous to try to do anything further. exit() will cause any atexit functions, and in C++ destructors of static objects, to be called. This is usually what you want for a clean exit, but it could be catastrophic if, for example, they overwrite a file with corrupt data.
Mike Seymour
2010-09-09 12:01:46
+1: but you also have others ways to do it. for not calling function registered as atexit you could also _exit() instead of exit(), or even send a SIGKILL to yourself for immediate exit.
kriss
2010-09-09 12:05:48
@Kriss: `abort()` is the standard way to do so, and easy. Why would you choose a non-standard method?
MSalters
2010-09-09 12:10:55
@kriss: `_exit()` isn't standard C or C++, and aborting by raising a signal other than `SIGABRT` seems a bit of an odd thing to do.
Mike Seymour
2010-09-09 12:18:01
@doc: No, I wrote this before I saw the other answer. It says more or less the same thing, though.
Mike Seymour
2010-09-09 13:16:13
@Mike Seymour and @Kriss: `_exit` is standard POSIX, so there it would be appropriate. C99 has `_Exit` which is similar to `_exit`.
Jens Gustedt
2010-09-09 13:17:48
@Mike Seymour: I'm not saying I would do it, just that these possibilities exists. Sending SIGKILL to myself ? Why not ? As far as I know it's allowed and standard Unix. And _exit() is also standard and does not dump core.
kriss
2010-09-09 14:08:03
@kriss: the question was about `abort()` vs. `exit()`, which are the two standard ways to prematurely end a program, and not about alternatives. `_exit()` is *not* standard C or C++ (it's defined by POSIX, but not by either language standard), so it isn't portable. Of course you can send `SIGKILL` to yourself, but why would you want to, when `abort()` more clearly expresses what you want to do?
Mike Seymour
2010-09-09 14:24:22
@Mike Seymour: my point is really in the comments of Andy's answer. You can argue abort() is to be used in debug contexts. What if I do not want core dumps ? That's what _exit and _Exit are for and they would work in cases where exit might not (because of atexit). And if they are not available, let's suicide.
kriss
2010-09-09 15:11:58
@kriss: I'm not really following what your point is, apart from there being non-standard (and standard but unconventional) alternatives to the functions this question is asking about. If the program gets in such a state that it needs to abort, then you *do* want a core dump. If you don't feel like debugging the crash (or sending a bug report, if it's not your code), then delete it, or suppress its generation with `ulimit -c 0`. Why should the programmer care whether the user wants a core dump?
Mike Seymour
2010-09-09 15:36:40
@Mike Seymour: it's like putting dust below the carpet. For commercial software the core will be badly perceived by some customers. And in some cases like network servers, relaunching an application that crash may not be a real problem. But I'm speaking of situations like when commercial department insists on publishing a bogus software, but wouldn't want it to be too obvious. Anyway I can't see a single case where you should use abort() for any legitimate case beside bugs. Do you ?
kriss
2010-09-09 16:26:08
@kriss: for commercial software, the catastrophic failure will be badly perceived by almost all customers. Most won't notice, or particularly care about, the core dump on top of that; some might be helpful enough to include it in their bug report. And no, I can't think of a use case for `abort()` apart from bailing out after detecting a bug; that's exactly what I said in my answer. Do you actually have a point to make, or are you arguing for the sake of it?
Mike Seymour
2010-09-09 16:39:31
@Mike Seymour: my understanding of abort() is that is what is hidden behind assert macro. In actual code I never wrote a single abort directly (but assert(false) is quite common). There is a real question behind that: should you include bugs facilities in production code. I have no definite answer on that. I also worked for firms selling software (network services) that crashed sometimes, was relaunched automatically by system and where problem was totally unoticed.
kriss
2010-09-09 16:57:13
A:
Abort is preffered when application doesnot able to handle the exception and not able to understand what to do scenario. Exit() mean application should must finish all task gracefully. if exception occurs and application is able to handle the same then Exit() call happens.
Santosh kumar
2010-09-09 13:08:28