Hi,

When to use exit(EXIT_FAILURE), abort or terminate?

I'm not eben sure where's the difference between those three.

Edit:

I realized that terminate calls abort.

Use exit(EXIT_FAILURE) if you want to exit normally and have an error code that you may be able to test from the shell. Use abort if you want to flag a critical error and generate a core dump.

exit() will call allegro_exit() for you, abort() will not. exit() is basically a shortcut you can use when an error occurs, and exiting all the way through main is too much trouble. abort() is for the more extreme cases.

If you're using C++, abort() won't call any destructors, while exit() will.

std::terminate is a C++ feature that is typically called when an exception is thrown without a corresponding catch block. Typically you would override this with something that outputs the trouble to your log.

There is also std::unexpected_handler which calls std::terminate by default. std::unexpected_handler is called when you throw an exception that is not allowed by the throw specifiers.

// foo may throw *only* int, char, or short.
void foo() throw(int, char, short)
{
    throw float(25);
}

void main()
{
    // Here std::unexpected_handler will be called which then calls std::terminate which then calls abort.
    foo();

    // Here std::terminate will be called which calls abort.
    throw 5;
}

std::set_terminate
std::set_unexpected

Also, abort() is not guaranteed to perform any form of cleanup, such as closing open file handles, flushing buffered but unwritten data or deleting temporary files. exit() is.

Thanks for your answers. But there are still questions left.

Isn't a program termination without cleanup a bad thing? Even if the program doesn't work as it should?

Is the core dump the only benefit of using abort?

I'm not sure if there's any reason to call abort or terminate directly.

Perhaps. Under normal circumstances, yes. But you wouldn't call abort() under normal circumstances.

Isn't it enough?
The fact that the program terminates without trying to do extra cleanup can also be an advantage, in situations where trying to clean up could further destabilise the system (although that isn't likely these days, since all programs are fairly well encapsulated).

There is if you want a core dump.
If there is a (critical) error and you call exit(), then you won't know where the error occurred (the program will exit cleanly). If you call abort(), you'll be able to catch the error at the point where it occurs. It's a debugging aid, which is why it's normally called by assert().

So if I have a case where something can go wrong, I throw an exception. I can think of two cases. Please tell me what do you think about it.

1. I don't catch the exception. It's a programming error. I get the core dump and I'm able to debug my program. This kind of error shouldn't ever get in touch with the enduser.

example:

an array index out of range.

2. I catch the exception to handle it. (retry with different settings, or output an error message). This kind of error depends on the surroundings. System settings, data files or user input. It's not a programming error.

example:

couldn't find a bitmap file.