Re: PEAR_Error, ErrorStack, Exception, and compatibility

Justin Patrin wrote:

If someone wants returns, they should have that option, *even in PHP5*. If you're worried about speed / parsing, PEAR_Error could be conditionally included when and if a PEAR_Error return is asked for.

I think that if PEAR decides to encourage new (php5) development using PEAR_Error, when PHP5 provides a full-featured built-in error handling system, then PEAR will simply never become an authoritative repository for PHP5 libraries. I think PEAR has an obligation to keep up with PHP development and encourage software that takes full advantage of language features. I argue that with an appropriately designed Exception base class you can do everything needed to catch and handle errors. Warnings can be handled by trigger_error() + set_error_handler() functions or stored internally to the object. There are a number of solutions for warnings and notices (e.g. trigger_error, $obj->getWarnings(), or something like raiseWarning()). I'm talking about replacing PEAR_Error returns with Exceptions. Anytime a function returns a PEAR_Error it should be throwing an Exception in PHP5.

And PHP5 is just an upgraded PHP4. Just because it has Exceptions, it doesn't mean that we *have to use them*. And if we use them, it doesn't mean that we have to use them for everything. And if you want to use them, in a perfect world, it doesn't mean that *I* have to use them. A single funciton call, a single switch, and a conditional include are a very small thing to ask for for greatly increased flexibility.

Having this perfect world where every calling package can decide on the error handling system is not practical. Having every module change the application's error handling system to something it understands -- and then back again, sounds performance-poor and just crazy design. So you would not get to choose whether or not you want to use exceptions, but that's no different from how it is now. I happen to dislike PEAR_Error, but I certainly have to use it (i.e. PEAR::isError()) in any of my classes that use a PEAR library.

And again, I resent that people assume I don't know what I'm talking about. I have used other OOP languages which have these features. Private and protected are *not new*. Exceptions are *not new*. I don't have to use PHP5 to understand the difference.

But why would anyone *want* to use PEAR_Error when there are exceptions? I can't understand this. Where's an example of some code that works brilliantly with return values but not with exceptions? From my perspective you can always accomplish what was possible in return-code error handling using exceptions and you can also do a *whole* lot more. I think people are telling you to try PHP5, because you haven't yet and it is very different. I think most developers that have used PHP5 see the differences as very welcome improvements -- and you are suggesting that we keep using PEAR_Error because it's what people are used to, or keep prefixing priv/protected w/ '_' because it's the way people are used to doing it, even if it isn't at all necessary in the new language. In refleciton, I think what all these debates do illuminate is that the upgrade path to PHP5 is anything but easy. Sure you can upgrade to PHP5 but not use any PHP5 features; that will certainly make the upgrade easier, but why upgrade at all then? The truth is that the ZendEngine2 is far from backwards compatible and new PHP5 code isn't going to work at all with existing PHP4 libraries. -- not without severely crippling the PHP5 packages -- and frankly, people aren't gonna want to do that. PEAR might want that because it's easier, but PHP developers aren't going to use PHP5-only libraries that don't use PHP5 features. Hans