Yes, I already acknowledged that PHP has a garbage collection implementation starting 5.3.0 and up (opt-in or opt-out, that's not the problem). I also acknowledge that garbage collection works, and is able to take care of most circular references just fine. [...] Anyway, as previously stated too, garbage collection is a great thing, but not enough for PHP. It's a borrowed feature that does not play well with old fundamental decisions inherited from the original design. Garbage collection is not a magical solution for every problem, like many tried to argue about. Let's illustrate with another example.

His example uses the React PHP library (a non-blocking I/O platform) to handle a lot of incoming data to a port and report back some memory usage and limit settings. He explains a bit about what's happening and shares the results of the test, including the end result - a fatal error when the memory limit was hit. He still comes to the same conclusion, ultimately...PHP is just not the language to use for long-running processes that do any large amount of work.

In my opinion, a lot of the hatred that PHP receives misses the utter basic point: PHP is meant to die. It doesn't mean that a perfectly capable (to some extent) programming language will disappear into nothingness, it just means that your PHP code can't run forever. Now, 13 years after the first official release in 2000, that concept still looks valid to me.

He talks about some of the "dying" that PHP is good at (like making general website-related requests) but notes that if you try to have it do much more, PHP acts up. He points to the complexity of web-based applications and notes that, while PHP is good for some of it, it's not a fit for all functionality. He also covers the bringing of processes to the foreground that are best left in the background and how - despite the best of intentions - making a PHP daemon to solve the problem isn't a viable option.

Do you see the pattern? I've inherited projects where PHP was used for daemons or other stuff that's not just regular websites (yes, I'm a hired keyboard), and all of them shared that same problem. No matter how good or clever your idea looked on paper, if you want to keep the processes running forever they will crash, and will do it really fast under load, because of known or unknown reasons. That's nothing you can really control, it's because PHP is meant to die. The basic implementation, the core feature of the language, is to be suicidal, no matter what.

As much as programmers attempt to anticipate every possible action or combination of actions that a user can take when encountering a web application, no one can foresee them all. When the user takes an unanticipated course of action and "breaks" the application, the software needs to catch them before they fall.

They show you a few methods for handling the errors that might come up including the die function, exception handling, triggering errors and just outputting errors via an "echo" or "print" (or something similar).

What's the most common pattern for error handling you see in beginner's PHP code? - That's right, do_X() or die('do_X failed);. That's nice and all, as at least you have some sort of error handling, but I think this way of handling errors must go. There is no place for it in modern PHP code - it's the worst way to handle errors, not much better than not handling them at all.

He talks about why die() is so bad and some alternatives to it - trigger_error (with a custom error handler) and exceptions. When used correctly, these two can help your script correctly catch and handle errors without the mess of a die().

I see it all the time, and I see people telling other people to do that all the time. It's plain simply bad practice and it's time that people start to understand this. When I confront people with it they usually say something along the lines of "oh, but it's just for debugging purposes". Okay, so I tend to put echo and var_dump() statements in my code for debugging as well. However, this is not the same.

They list several reasons why the "or die trick" is a bad idea including the non-catchable error that's thrown and that there's no control over where the error message from die goes. As a better alternative, they suggest using trigger_error and the exception handling built into PHP5 to correctly catch any potential errors a statement might throw.

Now, I have no actual authority to do so. My PHP CVS karma does not extend that far. And I doubt it will actually get removed despite it being nothing more than an alias for exit now. No, what I would like to call a death to is the usage of die such as [echoing out a message to the user instead of doing proper error handling].

He points out a few perfectly viable alternatives like the exception handlers, the trigger_error function and custom error handlers.

Scripts tend to die, and that's not usually nice. We do not want to show the user a fatal error nor a blank page (display errors off) . PHP has a function called register_shutdown_function which lets us set up a function which is called at execution shutdown. What this means is that our function will be executed when our script is done executing / dying and PHP execution is about to shut down.

He suggests various things that can be done with the functionality, including checking for successful script execution (via a false variable that can be checked for success).

Since error handling is something that you should introduce (at least progressively) into your applications, in this article I'll explore some of the most common error checking methods available in PHP, in order to make web applications much more robust and reliable.

The end result of this experience will be an illustrative list of hands-on examples that utilize different error handling methods, ranging in from using simple "die()" statements, to manipulating errors within an object-oriented context, by utilizing exceptions.

They cover things like the basic die() statement, triggering errors in your code with the trigger_error() function, using the error handling in PEAR, and setting boolean flags to catch when things go wrong...]]> Thu, 12 Jan 2006 06:34:19 -0600