27

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()?

mip
  • 8,355
  • 6
  • 53
  • 72

4 Answers4

36

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
  • 3,619
  • 20
  • 14
  • 3
    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 Sep 09 '10 at 12:44
  • @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 Sep 09 '10 at 13:12
  • @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 Sep 09 '10 at 14:11
  • @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 Sep 09 '10 at 15:42
  • 1
    @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 Sep 09 '10 at 15:59
  • 1
    @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 Sep 09 '10 at 16:33
  • @kriss "abort() is for bugs" -- yes, I think we're in agreement. – Andy Mortimer Sep 09 '10 at 17:06
  • 1
    Also, if you debug a program, the signal raised by `abort()` will usually drop you directly into the debugger. When using `exit` you'll have to set a breakpoint first. – nwellnhof Mar 07 '16 at 17:27
23

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
  • 249,747
  • 28
  • 448
  • 644
  • 3
    +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 Sep 09 '10 at 12:05
  • @Kriss: `abort()` is the standard way to do so, and easy. Why would you choose a non-standard method? – MSalters Sep 09 '10 at 12:10
  • @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 Sep 09 '10 at 12:18
  • isn't it a paraphrase of sharptooth's answer? – mip Sep 09 '10 at 12:57
  • @doc: No, I wrote this before I saw the other answer. It says more or less the same thing, though. – Mike Seymour Sep 09 '10 at 13:16
  • 1
    @Mike Seymour and @Kriss: `_exit` is standard POSIX, so there it would be appropriate. C99 has `_Exit` which is similar to `_exit`. – Jens Gustedt Sep 09 '10 at 13:17
  • @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 Sep 09 '10 at 14:08
  • 1
    @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 Sep 09 '10 at 14:24
  • 1
    @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 Sep 09 '10 at 15:11
  • @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 Sep 09 '10 at 15:36
  • 1
    @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 Sep 09 '10 at 16:26
  • 1
    @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 Sep 09 '10 at 16:39
  • @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 Sep 09 '10 at 16:57
  • 1
    @kriss Actually, `assert(false)` by its own is not a good way to panic on corrupted data: The assert may be stripped by the preprocessor, especially for productions builds where continuing with a corrupted state may cause real harm. I always use this instead: `assert(0 && "some message to help debugging"), abort()` This gives a core dump if at all possible, which contains the current call stack and line, and always terminates immediately. If you have no naked `abort()`, your production build may end up doing real bad things due to its corrupted state without signaling that anything's wrong. – cmaster - reinstate monica Mar 07 '16 at 17:19
9

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
  • 167,383
  • 100
  • 513
  • 979
  • 1
    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. – mip Sep 09 '10 at 12:00
  • 2
    @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 Sep 09 '10 at 12:04
  • 1
    Which is why you don't `throw` from destructors. If the destructor is called during stack unwinding caused by an exception, `abort()` gets called. – Rob K Mar 07 '16 at 20:28
  • 1
    @RobK You can throw in destructors. What you cannot is letting an exception leave the destructor. – sharptooth Mar 08 '16 at 09:03
  • 1
    @sharptooth that's what I meant. You don't let exceptions escape your destructor. – Rob K Mar 08 '16 at 15:34
2

Abort is preferred when application does not 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.

user16217248
  • 3,119
  • 19
  • 19
  • 37
Santosh kumar
  • 342
  • 1
  • 3
  • 6