Re: PEAR's Error Handling and PHP5

On 6/7/06, Justin Patrin <papercrane@gmail.com> wrote:

Some talking points: 1) Would it be possible for us to allow both PEAR_Error and Exception usage for PHP5 packages? Would this fragment our error handling too much? (This would, of course, require a version of PEAR_Error which is E_STRICT).

I think they can exist side-by-side myself -- more on that below.

2) Why are people so opposed to Exceptions form a technical standpoint?

Hear hear! I've been wondering this myself for some time. I've asked some developers, and typically end up with a conversation like, "I don't like exceptions." Why? "I just don't like them." I've read several blog entries where individuals mention they don't like exceptions, but fail to say why. I didn't start using them right away when I started using PHP5, but once I did, I couldn't understand why one *wouldn't* use them. Justin, you do a nice job of summarizing all the things I like about them in your pros list below.

Some pros and cons as I see them: Pro Exceptions: * Built into PHP, not as heavy as PEAR_Error (As I remember, this was one of the major upsides of Exceptions due to rampant criticism of PEAR/PEAR_Error as being too heavy) * Allows bubbling up without manually catching and re-returning errors (if the code doesn't handle the error in any way, why force the code to re-return it?)

This is one of my pet-peeves with PEAR_Error -- that, in order to continue bubbling up the error, I have to re-toss it at each level.

* Understood by programmers of other high level languages as a standard for error handling (C++, Java, Python, etc) * Will lower the number of mixed returns in PEAR code, meaning it will stop users from asking about "undefined method" errors (don't tell me you're not tired of explaining error returns to new users)

I've stumbled on this several times, and find it frustrating.

* [related to above] Will allow for cleaner and simpler example code (no need to catch exceptions, just let them kill the script normally) * Forces errors to be dealt with, it is not possible to forget to check an error return (this is a big pro IMHO) Con Exceptions: * Will cause multiple error handling paradigms to be used at once as likely PHP4 and PHP5 package will be used side-by-side for a time * They don't allow PEAR_Error's tricks such as changing error handling (dying, callback, etc), and expecting errors

Ah, but you can make the exception observable, which would allow you to do things like die(), execute a callback (perhaps to log or mail the exception), etc. You could even extend PEAR's setErrorHandling() method to register the mechanism with the exception class, and then handle it: class My_Error extends PEAR_Error { public static function setErrorHandling($mode, $options = null) {

       My_Exception::register($mode, $options);
       return parent::setErrorHandling($mode, $options);

} } class My_Exception extends Exception { protected static $_mode; protected static $_options; public function __construct($msg, $code) {

       switch (self::$_mode) {
           case PEAR_ERROR_PRINT:
               echo $msg;
               break;
           case PEAR_ERROR_DIE:
               die($msg);
               break;
           case PEAR_ERROR_CALLBACK:
               if (is_callable(self::$_options)) {
                   call_user_func(self::$_options);
               }
               break;
           default:
               // there's more, but this illustrates it...
               break;
       }

} public static function register($mode, $options) {

       self::$_mode = $mode;
       self::$_options = $options;

} } Obviously, you can't continue to process after the exception has been thrown, and some of these wouldn't make sense, but this was simply to get the idea across: you can do some interesting handling with exceptions.

* To allow code to continue when an error happens Exceptions must be caught, likely for every function call. (This is a con only when doing rapid prototyping and when you *want* to disregard errors. Note that most error conditions will caus ethe script to fail at the same point anyway, so this point is mostly moot for me. When creating a stable package and allowing code to continue you should be catching and storing the errors anyway. This could be done by using PEAR_Error/_Stack and a specialized callback, I suppose...)

And this is a perfect area where exceptions and PEAR_Error* can intermingle, to my thinking. Some errors shouldn't be fatal, but you might still want to know about them. Add them to the stack and continue on.

* They are an implicit goto (this is a very small con as this is essentially the same as returning errors from multiple calls)

I prefer this to having to do things like this all the time: $e = $object->action(); if (PEAR::isError($e)) {

       //...
       return;

} With exceptions, I do the first line of code and move on.

* Forces errors to be dealt with/rapid protytping becomes a little harder (this is IMHO a very small con, as said above, as most errors will need to be handled before code can continue anyway)

I agree with Justin here -- even when doing rapid prototyping you need to deal with errors. And with exceptions, I can deal with them like this: try {

       // do everything

} catch (Exception $e) {

       // hmmm... an error occurred. Let's do a backtrace

} -- Matthew Weier O'Phinney mweierophinney@gmail.com http://weierophinney.net/matthew/