iBlog - Ilia Alshanetsky

Lately it seems that the possibility of PHP developers agreeing on something is about as likely as peace in the middle-east being declared overnight.
After about a two week cease fire, following the long and bloody fight about studlyCaps aka suckyCaps, which ended with a sound defeat of the forces of sanity & reason the PHP developer community is at it again. Once more we can thank John Coggeshall for this bit of entertainment, this time centered around wondrous PHP5 feature called "Exceptions".
As you may or may not know in PHP5 it is possible to throw exceptions, which you can then catch and theoretically through this process simply error checking process and make it easier to write code. John proposed that all error messages raised by OO code would report errors by throwing exceptions rather then using the current error reporting mechanism. Technically the idea is sound good, since it would allow reduction in the number of error checks, allowing all error tracking be performed via a single try {} catch () {} block around the relevant code.
Alas theory tends to neglect practical problems and this is where the fun begins. In PHP an uncaught exception leads to a fatal error resulting in the termination of the script regardless of criticality of the error that had occurred. Which means that if you god forbid neglect to put exception throwing code inside the block, your script will break and worse yet not provide any meaningful information other then you having an uncaught exception somewhere. More over some PHP errors can be ignored in many instances, these include NOTICES, WARNINGS and PHP5's STRICT errors, by making them exceptions you can no longer ignore them and must catch the thrown exception. This is particularly annoying for database extensions where there are numerous instances where it may be safe to allow certain operations to fail. In fact certain optimizations rely on trying to execute a query and upon failure execute an alternate query thereby avoid locking the table(s) used for for the operation, which has significant performance benefits. Even outside of the database world, having exceptions thrown on every error can do more harm then good.
Let's take the Tidy extension for example, which is first extension subject to this new exception treatment. Certain operations such as setting deprecated libtidy options results in harmless warning that can be safely ignored as it does not have any affects on the generated code. However, with exception a harmless warning becomes an exception that must be handled. Consequently the script author who intends to use the simpler OO interface will now pay for that simplicity with interest by having to implement various error handlers to ensure that his script is not terminated prematurely by an uncaught exception. What's even worse that once an exception is triggered the code goes directly to the exception handler skipping any of the latter code, meaning that you have very little choice but to terminate the script execution yourself after logging the warning or error. This pretty much the usefullness of exceptions, who's original goal is to simplify the error handling code.

Yet another proof that the road to hell is paved with good intentions.