When it comes to coding standards there is one rule that always makes me cringe when I stumble upon it: "Lines SHOULD be less than 120 chars long. If not a warning will be issued." Let me try to make a point why I consider WARNINGS in coding guideline checks hurtful.

He defines a warning first, so there's no confusion (something that should be done, but doesn't have to) and why he thinks there's not much of a place for them in the code guidelines. He suggests that, by having them, they take away time from the real issues, the errors. He notes that "should" rules on formatting shouldn't be added to your QA tools right away. Adding too many of these that spit out too many warnings (not errors) could just muddy the waters and make the developers more confused.

The Zend Developer Zone has posted a new episode in their ZendCon Sessions series today - a recording of Eddo Rotman's talk on exception handling.

Welcome to the ZendCon 2008 edition of the ZendCon Sessions. [...] n this series we will be releasing regular sessions from ZendCon 2008 as we lead up to this year's ZendCon. This episode of The ZendCon Sessions was recorded live at ZendCon 2008 in Santa Clara, CA and features Eddo Rotman giving his talk: "Elegant Ways of Handling PHP Errors and Exceptions"

Harry Fuecks wonders in this new post on the SitePoint PHP Blog "how strict is your dynamic language?"

Considering the "big four" dynamic, procedural languages; Perl, Python, PHP and Ruby, to an extent they're much of a muchness, offering only small variations on the same theme (ignoring PHP's lack of support for functional-style programming). But sometimes little things make a big difference, and perhaps most of all when your code is given input to handle which it wasn't designed for. Knocked up a simple example to compare them in this area...

He compares four languages - Perl, PHP, Ruby, and Python - by giving, for each, code examples and what the output would be, including what would error out. These examples help to illustrate his final points:

On his Oracle blog today, Christopher Jones has posted a simple howto on getting the feedback the PHP Oracle functions throw when they error, only faster.

When a connection fails, you want to know about it as soon as possible. With Oracle Net there are many ways to configure connection and authentication.
For example a connection:

$c = oci_connect("hr", "hr", "abc");

could be evaluated by Oracle 10g as using the Easy Connect syntax to machine "abc" (using the default port and database service) or using a net alias "abc" configured in a tnsnames.ora file.

He includes some settings to add to the sqlnet.ora file to help speed thing along - setting the directory path to enable a different authentication syntax and changing a setting to restrict the types of connect methods the client can try.

To show how it all works together, he gives an example of the tnsnames.ora, sqlnet.ora, environment variables, and the commands he ran to test it all out.

Greg Beaver has a quick reminder on his blog for anyone out there running their own PEAR channels - "please watch pear-qa".

Just a quick note to all of you PEAR channel administrators: Please take a moment to either join the pear-qa@lists.php.net mailing list, or follow php.pear.qa at news.php.net. Why?

Every time a new release of the core PEAR package is slated, I (or whoever is in charge of the release) will post a message to the pear-qa list asking for testing of the new version 1 full week ahead of the scheduled release date. This is the one opportunity to test for critical errors that unit tests or myself have missed.

There's a specific instance he mentions of where this happened (in 1.4.7 involving channel names with a "-") and the code was still released. Of course, once it was applied, many users were upset that their installs had just "stopped working".

It would be very helpful to have channel administrators take a second to try out stable versions of PEAR as they approach release.

In this blog post today, ephemera looks at a few of the common PHP errors those new to the language might encounter and an inerpretation of each.

I'd like to dispell the myth that errors are a bad thing. Errors are not a bad thing. Errors are a good thing! They tell you exactly what to fix, and exactly where to fix it. The only mystery is in actually interpretting the language of the error, which is another skill that beginning coders have yet to master. What does the PHP interpreter really mean when it says "unexpected T_VARIABLE"? What's a T_VARIABLE, anyway?

This document is the first in a series that will attempt to help you decode error messages. This version is aimed at very new programmers, working in PHP.

The remainder of the post looks at four of the common errors that might pop up - "unexpected T_VARIABLE", "Maximum execution time exceeded", "Undefined index", and "Syntax error". Under each, she talks about what they mean and how to catch what they're referring to. There's also an example for each to show what the error-causing code might look like.