I ran across some code using exit to abort process a request as soon as an error was encountered. I'm not a PHP expert, but my immediate reaction, knowing FastCGI at a high level, is that would exit the process and is generally a bad idea. This wasn't the case with Nginx and my current PHP, but with ancient Apache versions, this was a problem. PHP's documentation on FastCGI was pretty sparse, but it did mention fastcgi_finish_request which looks like a graceful way to finish the request.
The documentation for exit is unclear on whether it has any performance implications for FastCGI, but there is the subtle distinction that it exists the script, not the process. The documentation for header actually uses exit, and I found the pattern in several Stack Overflow posts, but the justification was "so you don't send a body," not "if you don't emit a body after the header, the body will be empty and the redirect will work as expected."
I also found conflicting answers on whether or not it causes problems. That, and Dreamhost recommends against exit when using FastCGI (though their example's in Perl). The one place it definitely causes problems is unit testing.
So my question: what's the best practice for using exit in PHP web pages? Is fastcgi_finish_request a better choice? Would restructuring the control flow be better? Are the problems people reported Apache-specific? Or is this just another version of "are multiple returns bad programming practice?"
