I'd assume you'd mean segfaults. It's somewhat painful to track down a segfault in PHP, but if you can compile PHP with debug symbols and then invoke a failing scripts under gdb, it's fairly straightforward.
Syntax errors, calls to @nonexistant_name(), and many others will simply return an empty page and log the error to the error log (error is not catchable, so you cannot even return anything sane to the user)
The fun starts when you hit one of the situations where the whole php stacktrace is `in file "" at 0` (or something similar). I've got 4 php programmers around me and I hear about the "white page" almost once a week, so it's not that uncommon :(
That's not a problem with PHP, you just have your environment setup to return nothing on fatal error.
Shutdown functions still run after a fatal error (something I just learned), so you can display the error or redirect to another page:
function shutdown() {
if (($error = error_get_last())) {
ob_clean();
// report the event, send email etc.
// Redirect
header("Location: http://hostname/error");
}
register_shutdown_function('shutdown');
As for the empty stracktrace, I used to encounter those frequently but I don't anymore. Either Zend has been fixing them up, or I'm doing less work inside of various handlers.
There are several ways of catching uncaught errors and returning reasonable output to the client. First look into set_error_handler and set_exception_handler. Also you can register a shutdown function or set an output buffer callback that looks at error_get_last().
Well, you could turn display_errors to 'on' in the php.ini file, but this is generally regarded as a security issue, as the error message will reveal sensitive info.
There are some situations which cause PHP to just die and not log anything, but those are pretty rare.
It's pretty common practice to have display_errors to on for development, and off for production. Are you not doing that already? Or is everyone developing on production systems?
Bluesnowmonkey already gave you some specific solutions but I wanted to point out that error suppression is generally a really bad idea. If your code encounters an error you should want to know about it.
This is one of the reasons I really like working in Rails. An exception blows the page up properly, and kicks into my exception notifier (sends me an email with the environment and stacktrace) and can display an error to the user. PHP's "soft on errors" approach is just a timebomb waiting to go off. "Fail hard, fail fast" is less forgiving, but ultimately, helps me sleep a lot better at night.
I know that it blows up on fatal errors, and I know that you can have it report or not report errors (error_reporting), but how would I, say, make it terminate with a backtrace if I attempt to fopen a file that I don't have permissions to open? The proper behavior in PHP is to check your file descriptors, but I'd much rather it just give up and go home, since behavior after a failure like that is going to be unpredictable in many cases.
I assume you are talking about fopen-type of functions that are nothing more but wrappers around C standard library functionality.
Use SplFileObject (part of SPL that is part of PHP core) for object-oriented way to manipulate files. On a failure (like your permission issue) it throws Exceptions and if not handled this will result in a "hard" error with a backtrace log.
Awesome, thank you. I'm a bit rusty on best practices since I've shifted my focus away from php, but it's nice to know that options to make it behave a bit more high level exist.
