PHP to the Rescue!

If you’re looking for a thoughtful Saturday read, you won’t go far wrong with Error codes or Exceptions? Why is Reliable Software so Hard? by Damien Katz, which is worth it just for the visual interludes.

In fact it’s less about error codes / exceptions and more about what you do when something does go wrong – how to you “bail out” of the mess you’re in?

On the PHP fanboy front, the relevant piece that needs quoting…

What we need in languages and tools is the ability to easily isolate our changes for when the s**t hits the fan, so that incomplete changes aren’t seen (all or nothing). And we cannot be in denial that the s**t can hit the fan at any time. We need to make it easy to detect when things do wrong, and make it simple to do the right thing once that happens.

Believe it or not we already have it, in rudimentary form, in PHP. Yup, good old, stupid-simple PHP. On a webserver, PHP scripts have no shared state, so each instance of a PHP script runs in its own logical memory space. The scripts maintain no persisted state, so each script start off fresh as a daisy, blissfully unaware of what happened the previous times it was executed.

The only shared state in PHP exists at the database level (or file level, but don’t go there), and if you commit all changes in a single transaction, you’ve basically solved the deck building problem. Your code might not be better about successfully completing its update, but failure is isolated, all the actions leading up to a failure are forgotten about and it can’t cause further problems or inconsistencies in the application.

It’s that whole shared nothing thing again but re-spun with an emphasis on transactions rather than scaling.