Exit() Call Inside a Function Which Should Return a Reference

exit() call inside a function which should return a reference

This situation is so bad that the program cannot continue, so I print a message to help to spot the bug and call exit(1)

No. If this code is part of a library, the library should not be the one deciding if the application should exit or not.

What if a file is open and needs to be closed, or some other resource needs to be cleaned up, or if the user of your DB class wants to log the error and continue doing something else?

The answer is anything but what you're doing now. Throw an exception, return an error code, etc. but don't close the application down within library or class code.

Believe it or not, there was a commercial DB library that did exactly what you're doing (closing the app down). They got a lot of angry responses from users of their library as to why they're shutting the application down unexpectedly. And you know what -- the answer given to the customers was that "we felt the error was severe enough to stop the application, because our library can't continue to work properly". That is not only bad reasoning, it borders on arrogance, and the customers let them know that.

What is the best way to exit a function (which has no return value) in python before the function ends (e.g. a check fails)?

You could simply use

return

which does exactly the same as

return None

Your function will also return None if execution reaches the end of the function body without hitting a return statement. Returning nothing is the same as returning None in Python.

return statement vs exit() in main()

Actually, there is a difference, but it's subtle. It has more implications for C++, but the differences are important.

When I call return in main(), destructors will be called for my locally scoped objects. If I call exit(), no destructor will be called for my locally scoped objects! Re-read that. exit() does not return. That means that once I call it, there are "no backsies." Any objects that you've created in that function will not be destroyed. Often this has no implications, but sometimes it does, like closing files (surely you want all your data flushed to disk?).

Note that static objects will be cleaned up even if you call exit(). Finally note, that if you use abort(), no objects will be destroyed. That is, no global objects, no static objects and no local objects will have their destructors called.

Proceed with caution when favoring exit over return.

http://groups.google.com/group/gnu.gcc.help/msg/8348c50030cfd15a

using exit(1) to return from a function

exit() exits your entire program, and reports back the argument you pass it. This allows any programs that are running your program to figure out why it exited incorrectly. (1 could mean failure to connect to a database, 2 could mean unexpected arguments, etc).

Return only returns out of the current function you're in, not the entire program.

How to end the program from a function which is called in another function (C++)

You can return from all functions all the way to main (nicest).

You can call some variant of exit.

You can throw an exception.

You can use setjmp/longjmp to jump to the end of main (please don't).

You can crash the application (by calling abort, raise(SIGKILL) or similar).

I can't think of more options, but there may well be some...

PHP using exit() inside a function() to return only 1 value at a time

Use a function that echoes the error then dies after:

function checkEmpty($postValue, $msg){
if($postValue == null){
echo alert_danger($msg);
exit();
}
}

checkEmpty($city, "City cannot be empty"); //without echo

Is it safe to call exit() from a C++ function to terminate the program?

Some claim that exit() terminates the program normally, just as a return 0; would from main

std::exit gets called anyway, as part of standard application lifecycle. Quote from CPPReference:

Returning from the main function, either by a return statement or by
reaching the end of the function performs the normal function
termination (calls the destructors of the variables with automatic
storage durations) and then executes std::exit, passing the argument
of the return statement (or ​0​ if implicit return was used) as
exit_code.



Others claim that exit() doesn't call all the destructors, etc

It's true, but it doesn't cancel the first statement. I.e. if destructors of you classes don't have any side effects that can survive the program, it doesn't matter whether local were destroyed properly or not, since entire memory of your process is freed after program termination. std::exit however calls destructors of objects with static and thread local storage duration:

The destructors of objects with thread local storage duration that are
associated with the current thread, the destructors of objects with
static storage duration, and the functions registered with std::atexit
are executed concurrently



Related Topics



Leave a reply



Submit