is there a function which comes between where return() and exit() sit?
i want to say “no more output, end, finish”, which exit() certainly accomplishes, but exit() also kills the current process (which i think may be causing problems for me because the system i’m using uses fast cgi which uses the same process for multiple page requests i think – something like that), which is something that may be causing intermittent status 500 errors i’m seeing in my access logs. so i need to remove all uses of exit().
of course it’s possible to reorganise things and end all the page’s output with return()'s, but i’m just wondering if there’s a more heavy handed return(), but not as heavy handed as exit() so i don’t have to reorganise things, just replace exits with this function/method i’m asking about which may or may not exist?
If you don’t want such errors to come up, you will need to refactor your code. As I’m sure you’re aware, exit; kills the process, and a single fastcgi process manages multiple scripts per process. By shutting it down you’re removing the benefit of fastcgi entirely.
As far as I know, it shouldn’t affect anything other than giving you an error and maybe a slight performance hit due to having to restart fastcgi every time this happens. However if you want to prevent it, it’s going to involve a application rewrite - small or large depending on how your current application works.
well the hypothesis is i think, from my hosting company support guy, if the process is coping with more than one request at the same time, an exit() in page1’s code will stop page2’s code running wherever it is. hence why my 500 status errors are so intermittent and hard to track down and see. this certainly seems logically possible if a process handles page requests in an interleaved fashion, which they probably do.
seems like a real serious problem, if the theory is correct.
ah, having just thought and typed that, i thought i’d look at the exit php manual page and search for cgi, and…
If you want to avoid calling exit() in FastCGI as per the comments below, but really, positively want to exit cleanly from nested function call or include, consider doing it the Python way:
define an exception named `SystemExit’, throw it instead of calling exit() and catch it in index.php with an empty handler to finish script execution cleanly.
<?php
// file: index.php
class SystemExit extends Exception {}
try {
/* code code /
}
catch (SystemExit $e) { / do nothing */ }
// end of file: index.php
// some deeply nested function or .php file
if (SOME_EXIT_CONDITION)
throw new SystemExit(); // instead of exit()
?>
anyway, at the very least that confirms it is a real potential problem.
At least, as far as I’m aware, FastCGI doesn’t handle multiple requests scripts at once - rather, it handles them in succession. If the process is terminated, a new one starts up and the scripts after the one calling the exit will be passed to this new process. Correct me if I’m wrong.
The exception method is a good approach, but whether it is a viable solution or not depends how your application is laid out.
> At least, as far as I’m aware, FastCGI doesn’t handle multiple requests scripts at once - rather, it handles them in succession. If the process is terminated, a new one starts up and the scripts after the one calling the exit will be passed to this new process. Correct me if I’m wrong.
i have no idea if the fastcgi process handles page requests in an interleaved fashion or sequentially.
anyway, seeing as exits leave errors in the log and are wasteful of resources, i should get rid of exits somehow. i didn’t think/realise exit() would do that to fastcgi, in fact, when i wrote the code i wasn’t really aware of fastcgi or that it was going to be used on the system i was running code on. now i know
The main problem is that return and exit are not functions. They are language statements. You do not have to put () after either of them, and putting () after return is highly unusual.
Exit isn’t the problem. If you have a shutdown process, create a shutdown function that executes that process and ends with a call to exit.
The reason you are seeing 500 errors in the access log is that any argument to exit other than 0 or void may be interpreted by the handler as an error status. mod_php just returns the string passed and leaves the headers unaffected. It looks like that isn’t the case with CGI. PHP Sapi returns the string exit gives to the OS as an exit code, and in Linux at least any exit code other than 0 is an error code.
Best practice is to never have a string after exit unless you are certain you want the handler to consider the situation to be an error condition and log it appropriately. Even that is hit or miss since different handlers can be configured to react differently.
Now for the part where I walk gingerly to try not to come off as a jerk though there’s no easy way to say this politely. In your first post you erroneously called two key statements of the language functions. This means you really need to go back and read the manual some more, because there is a world of difference between statements and functions both in scope and purpose. You need to sort this out now before it causes more problems for you.
The main difference between statements and functions is that statements do not have to have any of their arguments (if they even have any) in parenthesis.
exit;
return;
Each of those is valid.
exit ‘time to go’;
return 'a string;
This is valid. Parenthesis can be used because they are a grouping operator.
The main problem is that return and exit are not functions. They are language statements. You do not have to put () after either of them, and putting () after return is highly unusual.