4 ms·

So... do they figured it out how to fix the PHP's white screen of death? This kind of thing is so annoying that I can't even think of using PHP in my future pro

So... do they figured it out how to fix the PHP's white screen of death? This kind of thing is so annoying that I can't even think of using PHP in my future projects.

cheald 16y ago
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.
- viraptor 16y ago
  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 :(
  - bluesnowmonkey 16y ago
    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().
  - mgkimsal 16y ago
    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?
  - wanderr 16y ago
    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.
    - cheald 16y ago
      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.
      - wanderr 16y ago
        PHP's behavior is configurable, it can be soft on errors or hard on errors. Unfortunately many lazy developers choose the former.
        cheald 16y ago
        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.
        simast 16y ago
        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.
  - wvenable 16y ago
    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.

So... do they figured it out how to fix the PHP's white screen of death? This kind of thing is so annoying that I can't even think of using PHP in my future projects.

cheald 16y ago

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.

viraptor 16y ago
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 :(
- bluesnowmonkey 16y ago
  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().
- mgkimsal 16y ago
  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?
- wanderr 16y ago
  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.
  - cheald 16y ago
    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.
    - wanderr 16y ago
      PHP's behavior is configurable, it can be soft on errors or hard on errors. Unfortunately many lazy developers choose the former.
      - cheald 16y ago
        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.
        simast 16y ago
        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.
- wvenable 16y ago
  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.