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.
April 30th, 2006 at 5:14 pm
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.
April 30th, 2006 at 6:22 pm
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.
April 30th, 2006 at 6:56 pm
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.
May 1st, 2006 at 7:46 am
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;
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.
On of the comments on Damien’s page makes a point to that effect;
May 1st, 2006 at 1:13 pm
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.
July 7th, 2006 at 4:47 pm
h r u
July 27th, 2006 at 7:56 pm
[...] If anyone’s willing, would be interesting to compare the example with IO, Lua and Erlang, where possible (side note: I did get the point—just pressing the PHP buzzer for fun—fascinated to see what Damien comes up with in CouchDB, especially the part about “Distributed, featuring robust, incremental replication with bi-directional conflict detection and resolution.”). Tags: perl, php, ruby, python [...]