Michelangelo van Dam has written up a quick introductory post on his blog about the process around throwing and catching exceptions in your apps.

One thing that I noticed was that although the code was well written [in the Zend Framework], implementing coding standards and best practices on many of the classes, I did notice a wrong usage of throwing exceptions (the try - catch statements).

He gives a few examples - catching a "divide by zero" the right and wrong way, how to grab/handle the message that comes along with the exception and how to define your own custom exception handler to help your code do more useful things with the errors it might throw.

Daniel Cousineau has posted a "quickie" over on his blog today dealing with error controllers in a Zend Framework application.

In my quest to do some alterations on ZF error handling (in particular, render the view if the action or controller is not found, makes it real easy for my designer to prototype) I had the desire to be able to allow modules to have their own ErrorControllers. Unfortunately, the Zend_Controller_Plugin_ErrorHandler() default does not allow for this and I didn't really want to extend that class (I planned on handling the rendering in the ErrorControllers) so I wrote up a quick plugin.

His plugin (code included in the post) hooks into the routeShutdown part of the routing process and overrides the default error handler for the module to pass the request off to his custom one.

In a recent post to his blog Dhiraj Patra looks at the caching functionality that PEAR has to offer via the PEAR Cache package.

Caching is currently a hot topic in the PHP world. Because PHP produces dynamic web pages, scripts must be run and results must be calculated each time a web page is requested, regardless if the results are the same each time. In addition, PHP compiles the script every time it is requested. [...] PEAR's Cache package offers a framework for the caching of dynamic content, database queries, and PHP function calls.

He talks a bit about what kind of methods are included with the package and shows examples of how it works for function call caching, caching the output from the script execution and how to implement your own custom caching extension of the main code to make it even more flexible.

DevShed has posted the final part of their series looking at the handling of file uploads in PHP5. This last installment shows how to take what yuou've learned so far and make things a bit more modular.

At this stage, you've hopefully recalled how to build an expandable file uploading application with PHP 5 that uses only one custom function to transfer a target file from a client machine to a predefined web server. However, in the beginning, I said that I was going to teach you how to develop a brand new file uploading application using an object-oriented approach.

The finish off the FileUploader class they were working on previously and show some testing examples of it in action.

On DevShed today, they continue their look at uploading files in PHP with the addition of some error handling features for their current script.

In this third tutorial of the series, I'm going to show you how to incorporate a brand new error checking module into the file uploading PHP script created in the last article.

They show the basic method - uploading with no error checking - before showing how much help adding in an error checking component to watch for things like files that are too large, invalid file choices and problems writing the file on the server side.

On the PHPClasses.org website there's a new entry covering, among other things, one handy feature PHP includes to let developers read and write their data more flexibly - streams.

This article explains what are stream handlers and how they simplify PHP developers lives by allowing PHP applications to easily read and write data from containers, like remote Web pages or e-mail messages, as if they were files. [...] The article also presents more examples of cool stream handlers classes submitted to the PHPClasses site by several authors.

He describes the abstraction that the streams interface allows, how they can make your life easier, a real-life example of streams in action (working with POP3) and some of the classes that have been contributed to PHPClasses.org that use them.

Continuing on from his previous post on output handling, Arnold Daniels shows how to build on the previous setup and add the ability to include dynamic data into the template.

For instance, it would be nice if the data in the left column, 'Beauty Tips', could be different for each page. There are several ways to solve this, but for know I will choose the simplest.

He takes a few steps to make adding the content simple:

• Adding markers for the title and left menu to the template
• Change the OutputHandler class to make it less static
• use setData() to title the page
• user setData() to add left column content
• Use mark() and endmark() to section off a part of the template.

He's provided a demo and made the source code available for download.

Arnold Daniels has a quick little tutorial posted to his blog about using the output handler in PHP (one of what he considers a technique that's "missing out" from normal PHP use). His example involves buffering the common page parts - like a template.

A website usually has a part which is common across all pages, containing the HTML header, the menu and those kinds of things. This is often solved in one of four ways. [...] All of these methods work, however there is a better way to solve this. You guessed it, by using an output handler.

He links to an example he's created and includes the code for his OutputHandler class to make controlling the content easier.

In recent work, Ian Selby came across something odd - a setup where PHP was segfaulting without any real indication of where the error might be:

Starting to get a little frustrated, I took a peek at my error logs (/var/log/httpd/error_log for the unitiated), and discovered a wonderful message [about the segfault]. As any person scratching their head would do, I hit up google.. to no real avail. Just a bunch of php bug reports. So, what happened, and how did I fix it?

After searching through the code and narrowing down where it could be, the culprit looked like a custom session handler he was using. It uses MySQL to store the sesion information and, unfortunately, when Ian had compiled the server he didn't let PHP know about his unique setup.

His default installation was trying to use the default MySQL information (including the socket) to reach the database. Obviously failing, the server simply gave up and segfaulted. Thankfully, all it takes it a recompile with a few extra parameters and you're back in business.

Brian Nelson has posted a follow-up to his previous article on creating a reverse proxy with PHP5, this time expanding on the functionality of it and reworking some to increase performance.

It's gotten a bit more complex; The proxy handler didn't pass all the client headers to the proxy server. This caused problems with having the wrong client type, no Etag caching, cookie passing, etc. Here's the current rev, which solves a lot of these issues.

The complete code for the proxy class included in the post and a note was added that there's now a Google Code project that's been created for it (svn repository).