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.

Win an Annual Membership to Learnable,

SitePoint's Learning Platform

  • Benjymouse

    I don’t get this. Is this implying that PHP is more mature in this matter than other web technologies. Because – quite frankly – that’s untrue. JSPs execute with no shared state. JSF, ASP.NET executes with no shared state. Tapestry executes with no shared state.

    For all of the above web techs, once a page is rendered it’s state is gone. *Unless* the programmer explicitly chooses to store state in a “session”. And that’s true for PHP $_SESSION as well.

    If anything, of all of the above, PHP has arguably the weakest exception handling.

  • http://www.tonymarston.net Tony Marston

    I think people who say that PHP’s lack of exceptions makes it impossible/difficult to deal with errors are, quite frankly, talking out of the wrong end of their alimentary canals.

    In software there are only two types of errors – recoverable and irrecoverable. It it is recoverable you display an error message to the user and ask him to choose what to do next. You do not need exceptions to achieve this.

    If it is irrecoverable then you don’t waste time asking the user what to do next as there is no choice. You produce a dump or stack trace or whatever and abort. Again you don’t need exceptions for this as PHP’s good old fashioned error handler does the trick admirably.

    People who can’t program without exceptions just aren’t good programmers. Period.

  • Fenrir2

    I’m sorry to say, but I think you missed the point of the article. It isn’t about php, and not about web programming either. It is about error recovery and functional programming.

    He does point out cases where exceptions are more expressive (sure, error codes could be used too). And he mentions a few other methods.

    You should read this article in a web programming context. It really is about general error recovery. He just compares the shared nothing architecture of PHP with functional programming, where every function is essentially shares nothing with other functions.

  • http://www.phppatterns.com HarryF

    I don’t get this. Is this implying that PHP is more mature in this matter than other web technologies. Because—quite frankly—that’s untrue. JSPs execute with no shared state. JSF, ASP.NET executes with no shared state. Tapestry executes with no shared state.

    For all of the above web techs, once a page is rendered it’s state is gone. *Unless* the programmer explicitly chooses to store state in a “session”. And that’s true for PHP $_SESSION as well.

    Think PHP was used by Damien by way of useful example to illustrate his point – as already commented the focus of Damien’s article wasn’t web programming (blame me for just pulling a quote out of context). It’s more that people should think more in terms of transactions when programming (or use a functional programming language) – think the GUI example he uses perhaps illustrates this best;

    An example might be if you have GUI application, and your code wants to add a dockable tool bar to the UI window.

    One approach is to add an empty tool bar to the UI, then add each individual button to the bar. This is wrong wrong wrong, because now you are mutating the UI program state for each button added, and if one tool bar button fails to be added, then the user gets a wacked-out, partially constructed bar. [...]

    Instead, the better strategy is to build the tool bar in isolation. Once the bar is completely constructed with all buttons, then add it to the UI in a single operation. This way you minimize the mutation to the existing objects (the top level window), instead we are only mutating our new object during its multi-step construction. If we fail to construct it fully, we can just forget about it and let the garbage collection get it.

    That said, if we are focused on web programming, it’s worth being aware that session state isn’t the only place you can shoot yourself in the foot – most platforms, except PHP offer you some kind of application state (which you don’t have to use of course), be it explicit or just static variables. In fact it’s the very notion of “application” which doesn’t exist in PHP – that you might call a bunch of PHP scripts in a web directory an application is by the by – when one of them handles a request, it is blissfully unaware of the other scripts in the directory. There isn’t some kind of startup phase with PHP, where a bunch of stuff get’s loaded into memory.

    I’m sorry to say, but I think you missed the point of the article. It isn’t about php, and not about web programming either. It is about error recovery and functional programming.

    On of the comments on Damien’s page makes a point to that effect;

    [...] the title is misleading. The answer to “error codes” or “exceptions” is (correctly) “depends on the situation” … but discussion on this is only a fraction of the article.

  • shai8181

    I’m sorry to say, but I think you missed the point of the article. It isn’t about php, and not about web programming either. It is about error recovery and functional programming.

    He does point out cases where exceptions are more expressive (sure, error codes could be used too). And he mentions a few other methods.

    You should read this article in a web programming context. It really is about general error recovery. He just compares the shared nothing architecture of PHP with functional programming, where every function is essentially shares nothing with other functions.

  • kapil

    h r u

  • Pingback: SitePoint Blogs » How strict is your dynamic language?