If you've been using the Zend Framework on a Windows platform (running IIS as the web server) and have been getting some 500 errors and have been left lacking the detail you need on the problem, you should read this new post from Rob Allen about an IIS setting that can help you out.

One of the dangers of frameworks in general is that you forget that they do lots of handy things for you. [...] The error handler in ZF will catch any exceptions and route them to the error action in the error controller. This then sets the correct HTTP response code, logs the error and optionally displays it if a config setting is set.

IIS shows you some default error pages when something goes wrong, but sometimes you might need a bit more information. Rob points you to the "Edit Error Pages Settings" panel in the IIS setup and which setting to change it to for development versus production environments.

In a new post from the Ask About PHP blog they look at handling different types of errors in a popular PHP framework, CodeIgniter, most being included with the framework.

The way I see it, there are 2 types of errors we have to work with. The ones which are displayed out in nice friendly text to your users, and the type which are hidden and shown only to you as the coder to figure out where something has gone wrong. CI provides the means to do both, thankfully.

They look at the error handling the framework provides for the system/application errors that might happen in the normal course of the use of your PHP application and the configuration file settings you can change to customize the level you want to report at.

Those using CodeIgniter on a PHP 5.3 installation might have noticed some error messages related to the datetime handling when you use related functions. Phil Sturgeon has a solution for you to get rid of those pesky messages.

Last night I set up Zend Community Server with PHP 5.3 and gave PyroCMS (running CodeIgniter 1.7.2) a spin. Out of the box v0.9.7.3 and v0.9.8-dev seemed to work fine, except for a single Warning at the top of each page. [...] To fix this, you only need to edit the main index.php for your CodeIgniter application.

He includes the code for a new section that sets the default timezone for the application and, if you want to help suppress errors like this in the future, he also shows how to change the error_reporting level. You can slo change these settings in the php.ini file, but this is a good per-application way to update those settings.

Paul Reinheimer came across a small bug in a recent PHP 5.2.x release of the language - a debugging message left in by mistake.

If you get an error when PHP launches along the lines of: "PHP Warning: PHP Startup: mm_create(0, /var/www/phpSessionStorage/session_mm_cli1000) failed, err mm:core: failed to open semaphore file (Permission denied) in Unknown on line 0" you're going to either need to upgrade to PHP 5.3.0 or wait for PHP 5.2.12.

It seems that some debugging code made it into the core code (but it's been corrected in the branches).

In a new post today Jani Hartikainen has pointed out a few errors that developers commonly make when writing and debugging their code.

Back in august, I introduced the error tracking challenge. While it didn't get as much participation as I had hoped for, I did manage to collect some results. In this post, I'll go through the most common ones, and suggest some approaches to avoiding them. Suggest your own errors and tips in the comments!

He's included issues in three major categories - boolean logic errors, typos/omissions and some common debugging mistakes. Inside each are some suggestions to help them make a less frequent appearance in your code: things like splitting up conditionals for readbility/ease of maintenance and being generally more careful in your development to reduce logic and small errors that could be picked up by the simplest syntax check.

On the Think Vitamin blog Kieran Masterson has put together an article about debugging PHP applications - everything from error levels out to a few useful tools that can help with some of the more complex issues.

Nobody enjoys the process of debugging their code. If you want to build killer web apps though, it's vital that you understand the process thoroughly. This article breaks down the fundamentals of debugging in PHP, helps you understand PHP's error messages and introduces you to some useful tools to help make the process a little less painful.

He looks at changing the display_errors setting, updating the error_reporting level, the types of errors (notice, warning, etc) and the Xdebug and FirePHP tools.

On PHPBuilder.com today there's a new tutorial from Marc Plotz about error handling in PHP apps - what it is and how to capture them to keep them away from your users.

Error reporting is there for a reason and should be used for the purpose it was built. [...] So what is it that we can do to stop errors from first giving out sensitive server information, and second killing our script half-way down the page? Luckily for us PHP has several built-in error handlers for us to use.

He looks at a few different ways to handle errors - additional checking around the operation (like a file_exists before a fopen), working with custom error handlers and the various error levels (like E_ALL or E_ERROR).

If you've had issues with an "unsupported protocol" message when working with the PEAR installation on your PHP instance, you should check out this quick post from the PEAR blog with a tip on how to fix it.

When trying to install something, you will get the error: pear.php.net is using a unsupported protocal '" This should never happen. install failed. This problem comes from corrupted channel files. Go into your PEAR php directory and backup .channels directory.

If you go into your PEAR installation and move the .channels directory out of the way then run an "update-channels" the issue should be corrected. Unfortunately, this also means you loose all channels you'd subscribed to, but does save you from having to reinstall PEAR completely.

DevShed has posted the third part of their series looking at the creation of dynamic twitter signatures. These signatures are the sort of badges you'd see on a site with the user's latest tweet and their photo.

In the third installment in this series, I will be demonstrating how to add proper object-oriented error handling to the SignatureImage class.

They've built up the class to take in a twitter username and, via a cURL request pull in both the account's avatar and latest tweets. If something goes wrong, though, the class needs to be modified to handle it. They show how to add in try/catch handling with an error handler method in the class to work with the error's result.

Sameer has posted about a list generated by CWE/SANS of what they consider to be the twenty-five most dangers errors you can commit in your application development (PHP related or not):

The document lists the most common and significant programming errors which can lead to serious software vulnerabilities. [...] The 25 vulnerabilities are divided into three main categories: Insecure Interaction Between Components, Risky Resource Management and Porous Defenses, details of which are listed below.

Some of the items in the list include:

• Insecure Interaction Between Components - Failure to Preserve SQL Query Structure ('SQL Injection')
• Risky Resource Management - External Control of Critical State Data
• Porous Defenses - Execution with Unnecessary Privileges
• Insecure Interaction Between Components - Cross-Site Request Forgery (CSRF)
• Porous Defenses - Use of a Broken or Risky Cryptographic Algorithm

You can see the full list here, including explanations for each.