C++: Understanding exit() in Sample Code

[Saladsamurai]

In a sample code that I have, we use the the following snippet to test whether a file has opened properly:

if (inputFile.fail())
	{
		cerr << "Error opening input file...check that file\n "
		"exists and is in current program directory. \n";
		[B]exit(1)[/B]; 
	}

The exit(1) is confusing me a little bit. I was under the impression that this acts the same way that return(0) does. But upon running it, there are apparently some differences. I am pretty new to this stuff, but it appears that when I use exit(1) the running of the executable does not stop entirely? If I want to run it again, I have to use the 'stop' button first (which implies there is something still running).

Can someone tell me if I am using exit() properly here? Thank you.

 

[jedishrfu]

exit(1) stops the program (buffers flushed, connections closed... program terminated but not always)

and the program will return an exit code of 1 that a shell script can interogate and decide what to do which is usualy to print a message to the user and stop.

Basically the value used as an argument to the exit() call is returned as a exit code to the shell script.

see: http://www.cplusplus.com/reference/clibrary/cstdlib/exit/

On Linux/Unix... bash shell... the command:

echo 'exit-code=' $?

will show you the value of the exit-code of the last command executed.

see: http://tldp.org/LDP/abs/html/exit-status.html

for WINDOWS/DOS: you'd use

echo Exit Code is %errorlevel%

or

if errorlevel 1 (

)

more details here for windows shell scripts:

http://stackoverflow.com/questions/...ication-exit-code-from-a-windows-command-line

 

[Saladsamurai]

exit(1) stops the program (buffers flushed, connections closed... program terminated but not always)

and the program will return an exit code of 1 that a shell script can interogate and decide what to do which is usualy to print a message to the user and stop.

Basically the value used as an argument to the exit() call is returned as a exit code to the shell script.

see: http://www.cplusplus.com/reference/clibrary/cstdlib/exit/

On Linux/Unix... bash shell... the command:

echo 'exit-code=' $?

will show you the value of the exit-code of the last command executed.

see: http://tldp.org/LDP/abs/html/exit-status.html

for WINDOWS/DOS: you'd use

echo Exit Code is %errorlevel%

or

if errorlevel 1 (

)

more details here for windows shell scripts:

http://stackoverflow.com/questions/...ication-exit-code-from-a-windows-command-line

Nice documentation link :!) for linux/unix. Thanks (I'm on a Mac)!

I changed my code to exit(0) and it does what I think I want it to be doing.

 

[AlephZero]

The C++ standard library works the same way on any operating system (well, it SHOULD work the same way ...)

There is no real difference between return i; and exit(i); if you use them inside main().

There is a big difference if you call exit(i); within any other function. Your program stops execution immediately, and never "returns" from the call to exit.

Of course if your program detects some error condition and there is no sensible way to recover from it, an "instant stop" can be exactly what you want to do.

Try something like this:

#include <whatever you need to make it compile on your system>

void mysub()
{
    cout << "hello\n";
    exit(1);
}
int main()
{
   mysub();
   cout << "goodbye\n";
   return 0;
}

and then replace exit(1); with return; and see the difference.

 

[Saladsamurai]

The C++ standard library works the same way on any operating system (well, it SHOULD work the same way ...)

There is no real difference between return i; and exit(i); if you use them inside main().


</snip>

Hi AlphaZero

What I was getting at was this: If you look at my console in the following screenshot, the big red stop sign is available for me to stop something when I use exit(1). If I use exit0, it is not avai;able for me.

 

[D H]

The big red stop sign is not available for you to stop anything. There's nothing to stop. It is there for you to examine the non-zero exit status.

 

[Saladsamurai]

The big red stop sign is not available for you to stop anything. There's nothing to stop. It is there for you to examine the non-zero exit status.

Hi D H

So, when I click on the stop sign, I am not presented with any 'examination' options. It simply says kill in the Console and says 'Debugging Terminated' which sure sounds like something is being stopped

 

[TylerH]

Apparently, the console is going into some kind of debug mode after receiving an error code. Returning anything but 0 is generally considered by the shell to indicate an error. As in, "return 1;" or "exit(1);" are considered to indicate the occurrence of an error. When you use "exit(0)" it means there was no error.

Essentially, you are ending your program after an error and not even informing the user that there was an error. This is bad for a couple reasons; the most important of which is that, if a script is using your program and your program fails because of an error, that script will continue to execute as if your program had done what it was supposed to do.

Just noticed: At the bottom of the console, it says "GDB: Debugging terminated." GDB is a debugger that is used to inspect a running (or stopped) program to see what caused a problem. When your program tries to abort using "exit(1)," something makes GDB start debugging your program.

Also, you may want to use "abort();" a function that does the same thing as exit(1) and return 1, but is more explicit.

 

[D H]

Also, you may want to use "abort();" a function that does the same thing as exit(1) and return 1, but is more explicit.

abort and exit are very different functions. abort causes abnormal termination while exit causes normal termination. If the argument to exit is non-zero the termination is still "normal," it is however unsuccessful. There's a world of difference between abnormal termination and normal but unsuccessful termination.

From the C standard, 7.19.3 (Files) ¶5:

If the main function returns to its original caller, or if the exit function is called, all open files are closed (hence all output streams are flushed) before program termination. Other paths to program termination, such as calling the abort function, need not close all files properly.​

In any implementation that complies with the standard, exit must call must about call functions registered with atexit, flush and close any open streams, and unlink files created with tmpfile. None of these behaviors is required for abort. On a Unix-compliant system, abort does flush and close any open streams, but this is not required by the standard.

On a Unix-compliant system, abort will raise the signal SIGABRT. The default signal handler for SIGABRT drops a core file and terminates with abnormal status given by the SIGABRT signal number.

The return status from a program on a Unix-compliant system comprises two bytes. One byte contains the termination signal (one bit of which indicates whether a core file was generated). The other byte contains the exit status in the case of normal termination .

 

[D H]

Hi D H

So, when I click on the stop sign, I am not presented with any 'examination' options. It simply says kill in the Console and says 'Debugging Terminated' which sure sounds like something is being stopped

The debugger is still running. The application is not. It's some (mis)interaction between the graphical debugger you are using with Xcode and the debugger gdb proper.

 

[Saladsamurai]

D H, AlphaZero, TylerH, and jedishrfu:

Thanks for all of your contributions. I am slowly getting better at this with your help. Thanks again!

-Saladsamurai