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.

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.

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.

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.

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.