Davey Shafik has a post today that talks about an exceptional change to PHP 7.0 and some updates that have been made to provide more of a hierarchy (a different one) that can make them easier to work with.

With PHP 7 errors and exceptions are undergoing major changes. For the first time, the PHP engine will start to emit exceptions instead of standard PHP errors for (previously) fatal, and catchable fatal errors. This means that we can now handle them much more gracefully with try... catch. But with this change, comes a whole new exception hierarchy.

He provides a tree of the error/exception relationships, what they inherit from and who their "children" are. He also talks more in detail about the "error" type exceptions: Error, AssertionError, ParseError and TypeError. He gets into more detail about catchable fatal errors and the userland handling of the Throwable type and extension.

Joshua Thjissen has a new post to his site today about a feature that's been introduced in the upcoming PHP 5.5 release of the language - the addition of "finally" to try/catch exception handling. He gets into it a bit more technically than just the "introductory" level, discussing parent/child exception handling and using returns.

Exception handling is available in PHP since version 5. It allows you to have a more fine-grained control over code when things go wrong ie, when exceptions occur. But since PHP 5.5, exception handling has finally evolved into what it should have been from the beginning: the "finally" part has been implemented.

He includes a basic example showing how a certain part is always executed, regardless of if the exception is thrown or not. He also shows how a "chained catch" would work to catch multiple kinds of exceptions and when the "finally" is run as it relates to the "trickle down" handling of exceptions. He then gets a little more complex and introduces "return" into the mix. Of special note, even if you return, the "finally" will still get called.

In this recent post to his blog Mike Purcell shares a method he found to discover the parameters required by a method in a class' parent via reflection.

According to PHP docs regarding the Memcached::get() method, there are three arguments which which must be added to my extended signature, which I added, but kept getting “...should be compatible with that of Memcached::get()” errors. I tried looking for the method signature via source code but didn’t glean anything useful from the PECL documentation, so I turned to PHP's RelectionClass.

He includes a quick snippet of code showing how the check works and the handy output it produces - a set containing the parameter name, if it's require or optional and it's definition.

On the Content with Style blog today they take a look at some buggy functionality with parent:: they've found in the latest version of PHP, 5.3.3.

So, this app I hadn't been looking at in a few months did not work at all. I traced the bug down to a method that itself called a parent method. The parent only contains __call and __callStatic methods, and for some reason __callStatic was called, although the class it was called from was an object instance.

After using some sample code from the PHP manual, they spotted how things truly worked - the call is always sent to __callStatic when called from the extending class but not when called directly. Apparently they aren't the only ones that noticed the bug but noted that it was removed in PHP 5.3.4 to fix the issue.

On the Re-Cycled Air blog Jack Slingerland has posted another in his "Dark Arts" series looking at some of the lesser used PHP features. This time he focuses in on daemonizing a process by forking it off into the background.

One of the many things you don’t often do with PHP (actually, I’m not sure you do this much with any language) is daemonize a process. A daemon is program that runs in the background (read more here). On Unix systems, processes are usually created by forking the init process and then manipulating the process to your liking. To create a daemon though, you need to get the init process to adopt your process. To do that, as soon as you fork the parent process, you kill the parent. Since you child process is parent-less, the init process generally adopts it. Once that happens, your process has been daemonized.

He uses the pcntl_fork function to spawn off the child process, detach it from a terminal window, create a ".pid" file so the system knows about it and then, of course, have the child script do something.

The AskAboutPHP.com blog has posted a helpful new tutorial for those using CodeIgniter out there - how to extend the native Model class to bend it to your will.

I'm in the process of creating models for my CI project, and realized that certain functions within the models were getting repetitive. Using CI's ability to create my own custom libraries, I was able to create my own custom 'Model' which extends from the core 'Model' object. How this simple architecture has cleaned up my code is simply remarkable.

Rather than overwriting the main Model.php file with some of your own changes, he suggests creating a new library, a "parent model" that can be extended instead to provide some common functions that all of your application's models might need. For something a bit more complex, he also points to this library that extends the models to give it CakePHP-like functionality.

On his CodeUtopia blog Jani Hartikainen gives an inside look at a feature of Doctrine, nested sets.

The Doctrine library comes with a feature called nested set, which makes saving trees in a database easy. However, it's quite easy to accidentally cause a lot of extra unneeded queries if not being careful. Here are some pointers to keep in mind while working with the nested set, and some example queries to make understanding it easier.

He gives an example, showing how to get rows from the database - parent and child - and some optimization tips to keep things light. There's also some pros and cons included for doing it either way (the standard fetching or using the more optimized versions).

On his Tower of Power blog Daniel Cousineau has written up a look at using a more detailed categorization method than just a parent/child relationship on your data - Tree Traversals.

If the software calls for only 2 levels of categorization (Parent and Child only), a simple nested for loop will suffice. However, software requirements change and you'll soon find yourself up shit creek without a paddle if you need to support 3 or 4 levels of nesting. [...] To those who's training is less formal (most web developers I meet have practical training, not formal), I'll help you out: Tree Traversals (or if you are completely lost, Recursion).

He creates a recursive function that, when passed in a category set with different types in it, can handle each of them and then calls itself again with the new child data. His sample code creates url out of a set of categories.

On his blog, Mike Lively has posted a look at some of the work he's been doing on patches for the late static binding functionality to be included in PHP, including an example of the updates in action.

This weekend I wrapped up a few small tests and sent the patch in and it was subsequently pushed to php 5.3 and php 6.0. Now, this is not at all the way I wanted things to work, in all honesty I think the patch is pretty hokey but unfortunately nobody really spoke up in support of the changes I wanted to make to parent:: in regards to LSB.

His example shows how to override a static method and push that new method's execution to the parent class (in two ways - safe using forward_static_call and the not so safe calling itself with a parent:: override).

In this blog entry Arnold Daniels talks about an issue he had in the past (needing a bit more functionality than the PEAR DB library could offer) and how he ended up solving it with what he calls a "dark corner" of PHP - class casting.

PHP has a function serialize, which can create a hash from any type of variable, scalars, array, but objects as well. Using the unserialize function, PHP can recreate the variable from the serialized hashed. If we look at how an object is serialized, we see only the properties and the class name are stored.

His method allows for class manipulation via changes to the serialized class information (like changing the value of the name parameter). His "casttoclass()" function makes changing this value simple.