Since PHP 5, there has been a bundle of built-in exceptions - the "SPL exceptions" - in PHP. However, the documentation for these classes is quite lacking in examples, and it can be difficult to understand when you should be using them. The short answer is always.

The list of exception types he recommends include:

• BadMethodCallException
• DomainException
• LengthException
• OutOfRangeException
• UnexpectedValueException

For each he gives an example usage of it, sometimes including a bit of code to illustrate.

While pure object-oriented languages produces mainly exceptions to signal an error, PHP started out as procedural and so it has a wide range of errors that can be raised along with exceptions.

He talks about a few of the most common error related issues:

• Exceptions
• Errors
• Error Types (E_NOTICE, E_PARSE, etc.)
• php.ini directives
• PHP functions for setting error handlers

Exception handling in PHP is not a new feature by any stretch. In this article, we'll discuss two new features in PHP 5.3 based around exceptions. The first is nested exceptions and the second is a new set of exception types offered by the SPL extension (which is now a core extension of the PHP runtime). Both of these new features have found their way into the book of best best practices and deserve to be examined in detail.

Some of the features he talks about were pre-PHP 5.3, but the focus is largely on these new features. He gives a bit of a background on exception handling in PHP and how custom exceptions could be thrown. He then moves on to the new features - first nesting exceptions and then some about the new core exception types (found here). All that being said, he includes some code to show the dynamic/logic/runtime exceptions in action including a look at best practices in library exception handling.

The other day I was thinking of programmer types. In a way, I think there are three kinds of programmers when looking at a high level [...] So how do you determine if a programmer goes into one of these categories?

The "just a programmer" is the developer that writes code because it's a better job with little passion. The "smart programmer" are talented developers but they miss the big picture things. The "smart and get things done programmer" can be the most ideal of the three - they're the ones with the vision and passion to really make great applications.

As a committed user of open source technologies, the difference between me using something and not using something is the documentation. Is there documentation for it? Is it easy to find? Does it answer my questions? Is there someone I can call an idiot if I disagree with the level of documentation? These are all very important questions.

He uses the illustration of the documentation of the CakePHP framework that's helpful, but only really after you learn how to use the framework in the first place. He mentions people on both sides of the fence - those that love the framework and love the documentation and those that moved on to something simpler because they just couldn't get it.

He also mentions the variety of sources that can provide "documentation" for the framework when you're getting a bit stuck - everything from blogs to The Bakery to a different sort of documentation, unit test.

Quite a few people have chimed in on a recent discussion about PHP, MySQL, database abstraction layers, and performance. I think enough viewpoints have been covered that I don't need to comment, but one question I don't see answered is "what are the qualities of a good SQL abstraction layer?" I think it's a very interesting - and complicated - question. As it turns out, the term has several meanings, and I think it's important to understand them.

The four types he lists are:

• Libraries that provide access to a database
• Libraries that present a common interface to different server software
• Libraries that write portable SQL
• Object-relational mapping software

OWASP (Open Web Application Security Project ) released a top ten list for web application security vulnerabilities in 2003 and 2004; you can find the latest information about their Top Ten Project here.

Most of the top ten vulnerabilities including (A1) Unvalidated Input, (A2) Broken Access Control, (A4) Cross Site Scripting (XSS) Flaws, and (A6) Injection Flaws, can be avoided by using these filters.

They walk through the installation before talking about the types of filters at your disposal - paranoid, SQL, system, HTML, int/float, UTF-8, and LDAP. The check() function looks at the inputted value to see if it passes the test (the other option the function takes).

They also give an example of combining filters as well, making more secure validation even easier.

There's a few different error handling types that Damien mentions

So, how can I help, you ask yourself sitting there behind your keyboard? Well, it's simple, really - Jim has set up a CafePress shop with some great t-shirts for purchase - and 100% of the funds made from the shirts will go right back to the kids at the school.

Slogans on the shirts include: