Re: PHP5 - Exceptions and the future of PEAR_Error

Thorsten Suckow-Homberg wrote:

Having been brought up in PHP exclusively, I'm rather naïve to the whole idea of exceptions. Could someone explain how throwing exceptions would rid me of if(!DB::isError($result))?

Since I started my "programming career" with Java, I think Exceptions is a great concept of error-handling.

Hi, PEAR is taking a "wait and see what the problems are" perspective. Exceptions have a great potential advantage: separating error handling from the normal flow control. With PEAR_Error, we have to use PEAR::isError() checks at every function return, or use a callback, but this method doesn't allow easy jumping out of a loop for serious errors. Instead, the isError checks slowly cascade up the hierarchy. However, exceptions are not a magic pill that will solve all error handling problems. Exceptions break the normal flow control similar to a break statement in this PHP4 code do { // do something break; // nothing here is executed } while (false); if you call a method that might throw an exception, but the exception may be recoverable, you MUST surround the call with a try/catch block or you run the risk of getting a fatal error or worse, skipping a bunch of important code when it shunts to the higher level catch. try { // do some stuff that throws an exception $foo->bar() } catch (Exception $e) { // handle any recoverable exceptions } suddenly, you're forced to handle errors in the normal flow control, just like PEAR::isError(). The only difference is the kind of punctuation: $e = $foo->bar(); if (PEAR::isError($e)) {

    // handle any recoverable errors and return everything else

} try {

    $foo->bar();

} catch (Exception $e) {

    // handle any recoverable exceptions and throw everything else

} If you are calling a PEAR package that has the try block above, and the package isn't quite working, it could be very, very difficult to track down the source of the error if the try/catch block is buried 7 or 8 method calls deep into the source. Also, if you don't handle an exception, you will get a nasty fatal error. Try this code: <?php // unhandled exception throw new Exception('oops'); ?> You have to know every exception that might be thrown and handle them. This can lead to: try {

    $a = new foo('something', 'wrong');

} catch (DB_Exception $e) {

    // handle DB Exception

} catch (IO_Exception $e) {

    // handle IO exception

} catch (Foo_Exception $e) {

    // handle foo exception

} catch (Exception $e) {

    // handle any other exceptions

} Suddenly, you can't read your code because there are thousands of "catches" all over the place. For these reasons, I believe exceptions should be used for only extreme errors - exceptions or faults - and not for trivial things like invalid parameters passed to functions. Think of it this way. If you would trigger_error() anything other than an E_USER_ERROR, an exception is inappropriate. I've been trying to come up with a solution for a while, and there is one available in the PEAR package, version 1.3.1. It's a class called PEAR_ErrorStack. The class allows you to keep all error handling centralized, but also is flexible enough to work with both PEAR_Error and Exceptions as needed. Greg