In the last two entries we have talked about the concept of layer abstraction: that is, that exceptions should not be allowed to pass out of one layer and into another. So, when an exception is raised in the database layer it should be caught in the controller. But how do we go about making sure that exceptions raised in the database layer are properly recorded and processed, ensuring that we have error logging and don't simply silence our exceptions?

He looks first at general exception nesting then at extending the base Exception class to write more nested code (inside a class). He also touches on the nested exceptions that were included in the latest release of the PHP 5.3 series.

A short quiz this time, but that doesn't make it less fun. Do you know the answer to all of them? Get a cup of coffee and kill 10 minutes with round two... As always, think of the answer before you execute the code or look it up. You can find round one here.

This one has questions on arrays, ArrayAccess, references, operator precedence and nesting structures. There's no answer key, so you'll just have to test it out if you want to see the answer.

I installed PHP 5.2 on one of my testing servers today and a couple of bits of code that previously worked fine in version 5.1.6 threw fatal errors in the new version. The error message was "Nesting level too deep - recursive dependency?" and it took a little time to track down the root of the problem. Here's what I'd done wrong.

Basically, his problem was using the "non-strict" evaluation for checking if two objects were equal to each other (== instead of ===). This compares everything about them, down to the properties - even if they're references to other properties inside of the same class (which is where the problem lies).

So, the fix is simple - === instead of == when comparing those objects. You'll be happier for the change.