On PHPBuilder.com today there's a new article from Jason Gilmore sharing what he calls "four sane solutions" to help you debug your PHP applications better than just an echo or var_dump.

Few tasks are more tedious and frustrating than debugging a Web application. [...] Fortunately, PHP developers have a number of powerful debugging solutions at their disposal. Whether you're merely inspecting array contents or attempting to determine the status of an Ajax-driven POST response, these four solutions are guaranteed to have an immediate impact on your productivity.

His four solutions involve changing the error reporting level on your development environment higher than production to catch issues that might slip through unnoticed, using XDebug, integrating FirePHP and using test-driven development to be sure things work from the outset.

Brian Moon has called for the death of die():

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.

Douglas Brown has posted some hints to help you find errors in your PHP scripts all centered around error reporting settings.

There are several methods to solve errors in PHP code. Sometimes when the user waits to see an output a blank page will be shown if there is an error. To show the errors E_ALL^E_STRICT is used for the PHP 5 version. Contrarily, remaining versions just use E_ALL.

He talks about the log_errors and display_errors settings in your php.ini, the error_reporting function call or a custom error handler as shown in this example from the PHP manual.

In this new post to his blog, Richard Thomas talks about a bug issue that he's "gotten in the middle of" and the conflict between the PHP group and the PEAR developers that came out of it.

Today I managed to get right in the middle of this. [...] Both pear and php are pointing the fingers at each other, neither seem to be able to work together and Im not even sure if either one of them has even taken the time to run my test code and realize what the issue is to begin with.

The problem comes when he created a a script with the Pear Mail, Mail_mime and Net_SMTP PEAR classes and, following the execution of the rest of the script, tried it both ways - turning the erro reporting back off or not messing with it at all. As a result, the code with the ending error_reporting() call throws an error, the one without does not.

Unfortunately, at the time of this writing both sides are still pointing at the other for blame on the issue.

In this new post to his blog, Richard Thomas talks about a bug issue that he's "gotten in the middle of" and the conflict between the PHP group and the PEAR developers that came out of it.

Today I managed to get right in the middle of this. [...] Both pear and php are pointing the fingers at each other, neither seem to be able to work together and Im not even sure if either one of them has even taken the time to run my test code and realize what the issue is to begin with.

The problem comes when he created a a script with the Pear Mail, Mail_mime and Net_SMTP PEAR classes and, following the execution of the rest of the script, tried it both ways - turning the erro reporting back off or not messing with it at all. As a result, the code with the ending error_reporting() call throws an error, the one without does not.

Unfortunately, at the time of this writing both sides are still pointing at the other for blame on the issue.