On PHPMaster.com there's a new article that suggests that suppressing notices thrown from your code is a bad practice to get into, both through error reporting and the use of the suppression operator, "@".

The PHP notice suppression operator is somewhat of a controversial topic in many circles. Some overuse it, some don't use it at all, and some don't even know it exists. Apologies in advance for the horrible code you're about to witness in this article, but it serves a purpose to illustrate the usefulness (or lack thereof) of the suppression operator.

He talks about some of the common notices and how the suppression operator prevents the "Notice" message that could come out of it. They suggest, however, that there's never a good time to use the operator, especially during development. Obviously, there are a few cases (they point out one with mail) where it could be useful. There's also some sample code for a custom error handler you can use to capture the issues that might come up.

In this quick new post to his blog Mark Story talks about two new errors he ran across when upgrading his installation to PHP 5.4, both showing up under E_ALL.

I've been running the PHP5.4 RC builds for the last few months, and there are some interesting changes in the upcoming PHP release. On top of all the great new features coming in PHP5.4. After updating to PHP5.4-RC4, a few things that used to not trigger errors and silently do the wrong thing, now trigger notices or warnings.

The two he mentions deal with a new warning on illegal string offsets and the other about string offsets ("Notice: String offset cast occurred"). You can find out about more changes in the PHP 5.4 series in the various Changelogs for each Release Candidate and beta release.

If you've ever been bothered by those pesky NOTICEs when running your code, you know that you can wrap evaluations or check things with an empty or isset call to make them go away. Brandon Savage has a new post that can help you decide which one to use when, though.

As developers, we want to develop code that never emits notices or warnings, and PHP gets a bit antsy when we develop code that utilizes uninitialized variables. Lucky for us, PHP makes it easy to test for these variables without getting these notices. [...] PHP (like most languages) evaluates a logical argument left to right. For an AND condition, both conditions have to be true; PHP stops evaluating if it finds any condition untrue.

He suggests that the case to use isset() is more when you just want to use another check in the conditional but don't want to be bothered if the variable isn't there. A call to empty(), however, also evaluates the contents of the variable if it exists. Be careful, though - empty() returns false if the value of the variable is false - so take care in your use and always test scripts with multiple values.

Brandon Savage has posted the next article in his "Scaling Up" series, a look at reducing the amount of "drag" your application makes through its processing path and some tips to help increase its "lift" out of some common problems.

The intuitive will note that many if not most of these suggestions are performance enhancements, not scaling techniques. Why then are they in an series about scaling? Scaling is about more than just adding hardware. It's also about making sure your system runs better. You can add lots and lots of hardware but you will someday be unable to compensate for bad queries and poor optimization.

Some of his suggestions include taking care of any sort of errors or notices (anything that could slow the script down by writing to a log), defining virtual hosts instead of making excessive use of .htaccess files and installing caching software to maximize code and information reuse.

On PHPFreaks.com there's a new tutorial providing a beginner's guide to debugging in PHP (with the built in functionality PHP has, not external software).

Everyday the forums see probably hundreds of topics posted where the problem is a fairly simple error. [...] As a beginner, it can be difficult to find and solve these errors. By tackling each of these in turn, I hope to teach you some methods of finding and solving them.

They look at the different sorts of errors - syntax errors, fatal errors, warnings, notices - as well as some of the ones a bit harder to track down like database problems and logical errors.

Greg Beaver points out an obscure problem he came across when working with the new _HALT_COMPILER token in PHP 5:

A quick note about an obscure problem peculiar to PHP files that make use of PHP 5's new __HALT_COMPILER(); token. Prior to PHP 5.2.2, if you included two files that contained the __HALT_COMPILER(); token, you would get a notice that __COMPILER_HALT_OFFSET__ was already defined.

This posed a problem for him as he needed it to throw this error for the phar library format. His solution? To patch his installation (PHP5, the PHP6 patch is here) to make the problem a non-issue.

Ivo Jansch discovered something interesting by way of an applicant's resume - a hidden "trick" that PHP pulls on the user when they try to use a Java-like syntax with System.

So yesterday I was reviewing a code sample that a job applicant had written during a test and I encountered the following line of code: It's not hard to guess what his background was :), but I was initially stunned that this actually works in php.

After a little investigating (and ruling out the Java Bridge), Ivo found that the line was being interpreted literally and was just being handled as a string instead of a constant. He gives two other examples to help with clarification.

While testing the eZ components framework on the latest version of PHP (PHP 5.2), Derick Rethans noticed a problem - a new "Notice" message appearing related to a __get call.

The first issue is an extra notice in some cases. This all works 'fine' with PHP 5.1, however with PHP 5.2 the [following] notice was generated for this code.

The cause? Well, the magic function __get only returns the variables in read mode so they cannot be written to. In Derick's situation, there was a foreach that was trying to use the values in a read/write mode. As a result, the error was tossed. He does provide a workaround, though, involving casting the information into an array.

Pierre-Alain Joye notes today that there were some issues with the PEAR HTML_Template_IT package he's a lead programmer for.

An annoying bug in the ITX callback system introduced a couple of months ago has been fixed. I would force me to write 100 more tests if I forgot again to run them before a release. But the bug seems to not have affected too much people (no related bug report) :-)

The other two are a PHP notice and a warning. For some reason fread decided to raise a warning when the content is zero, it will be fixed in PHP soon, but I still have to fix it in my code.

You can either check out the HTML_template_IT homepage for more or just grab it directly.

On his blog, Justin has posted an article from David Sklar today - a look at PHP error reporting - conifguration, locating errors, and checking variable values as the script runs.

Whether you're a PHP newbie or a wizard, your programs are going to have bugs in them. Nobody's perfect.

This article gives you some techniques for finding and fixing the problems in your programs. It covers three topics: how to get the PHP interpreter to report the errors that interest you, how to locate basic syntax errors in your program, How to check the values of variables as your program is running.

The configuration section mentions the display_errors and log_errors options to help debug your scripts. There's also a bit describing what the different error types mean (parse, fatal, strict) and simple things to look for to handle them. He also suggests some other resources to look at to help with more detailed error reporting...