When executing code at the command line using php -r and PHP 5.2.5, be sure not to extend the Exception class. It will cause a segmentation fault.

He includes examples of the issue that would cause the problem and the bug he's filed in an effort to get it fixed.

Some highlights from the meeting include new/upcoming RFCs for package naming schemes, exception handling in PHP 5.3, and a vote on extending the current PEAR2 Policies. Heavy stuff, check it out!

You can check out the full notes here on the PEAR portion of the PHP.net wiki.

With PHP 5.3 coming up on the horizon, I'm of course looking forward to using namespaces.

He gives an example of how useful these namespaces can be for you and your code, but points out one failing point - trying to define classes in a namespace that are named the same as a built-in keyword for PHP. There's already been a suggestion to add a captial "I" in front of the class name to prevent this collision.

There's also the problem of throwing custom exceptions - unless you use the namespace properly your script will just throw a default exception.

This large, complex subject offers numerous possibilities for experimentation, which means that you'll surely have tons of fun creating timing systems with PHP. [...] his article, then, will be focused on evaluating different scripts that fetch sets of records, first from a database, and then from flat files.

They use the Timer class they defined in a previous part of the series and wrap it around both a database class (pulling user information from a MySQL database) and a fetch to a flat file for similar information. General exceptions are handled as a part of the resource connection class.

While I would personally prefer an exception to be thrown in the first place, it is pretty easy to convert errors to exceptions in PHP.

His example is pretty simple - you set a custom error handler in your script that pulls in the error information and tosses an exception based on the error number the handler is given. Then you can use the try/catch method to see if your script has tossed an exception of the fatal error type. Nice simple solution to handle an interesting little problem.

A useful new feature in PHP 5 is exception handling via the try/throw/catch paradigm. An exception may be thrown and caught. If an exception is thrown in code surrounded by try, the following statements will not be executed, and the exception will be handled by the first matching catch block.

He gives a high-level overview of how Exceptions in PHP5 work and includes a simple example from his work with his DIY Framework.

In this last article of the series I'm going to introduce some additional modifications to the current signature of the "__autoload()" function to make it throw exceptions that display more useful error messages.

They start by setting up the application to have something to build from (a series of PHP scripts). They add on the exception handling to throw the custom error (the "class not found" they mentioned).

This is the third article in the series on how to auto load classes in PHP 5. This article will demonstrate how to trigger exceptions in a way that can be caught by the corresponding "catch()" block. [...] Nonetheless, this issue can be fixed with relative ease. That will be the goal of this third article of the series. So if you're interested in learning how this solution will be implemented, don't waste any more time and start reading now!

They start by looking at throwing an exception with the __autoload so that the script can catch it. The go back to mention the method they'd talked about before - using just eval() - and then show the "new and improved" method of handling the result with a try/catch block instead of a direct output.

Bearing in mind this intrinsic limitation exposed by the "__autoload()" magic function when it comes to triggering exceptions at runtime, in this second article of the series I'm going to show you some basic workarounds that you can implement to provide this function with the ability to throw exceptions when a determined source class fails to be included.

They give two examples of the use of the __autoload function as well as a method to capture the fatal errors that it might throw (using an eval inside of it to check on the class).

Last week we left off with an example where notice, exception and log levels are sent to the client. This week we present more POSTGRES exception examples, and continue with our article on Postgres exception handling.

They create a few examples:

• handling other error conditions with OTHERS
• using f_ex2
• returning NO_DATA_FOUND and TOO_MANY_ROWS
• handling exceptions like table constraints
• nested exceptions
• using f_ex5
• a RAISE EXCEPTION dilemma
• using f_ext1