Re: PEAR_Error, ErrorStack, Exception, and compatibility

David Costa wrote:

On Jun 22, 2004, at 10:47 PM, Justin Patrin wrote:

I think this discussion may have been lost in the multitude of messages in other threads, so I'm starting a new thread. There has been lots of talk about Exceptions in PEAR. Many people are saying that PHP5 PEAR classes should not use PEAR_Error at all and only throw exceptions.

you can't use PEAR_Error. You can't include PEAR. THis because PHP 5 only PEAR packages should work on E_STRICT.... Thomas was kind enough to do a PEAR exceptions class for error handling see http://cvs.php.net/co.php/php-src/pear/PEAR/Exception.php?r=1.1

I know of it and it is very nice, we should definately use that.

This can cause many problems: 1) The code is not compatible with PHP4

E_STRICT PHP 5 code, as it was suggested by Lukas and others as a requirement for PHP 5 packages, will never work with PHP 4 includes

Ok, everyone seems to want E_STRICT. This method will still work with PHP5. We just have (as we will have to) a PHP5 only version of PEAR and PEAR_Error. These can be stripped down a lot, of course, but still give the same functionality. I'm proposing this solution for a number of reasons, the major one being that people like to handle their errors differently. 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.

2) Some people believe that Exceptions are supposed to be for Exceptional circumstances, not general error handling

Yes I was one of them. Then I spent some time listening to Hans and others and here am I. It doesn't really matter what we believe but what PHP 5 is.

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. And not only would this provide everyone options, it would allow an easy upgrade path from PHP4 to PHP5 as packages could still get their PEAR_Error returns.

3) As per 2), it forces the user to handle errors in a certain way. For this reason, I propose the following: Backwards compatibility would be very simple by simply allowing a mechanism (through PEAR_Error/Stack) to throw the error as an exception or return a PEAR error. Here's what would happen.

You can't

You can, by using different versions of PEAR[_Error] for PHP5. You could even use a special include as such: PEAR.php: if (version < 5) { require_once('PEAR4.php'); } else { require_once('PEAR5.php'); } I'm sure no-one will want that, though. Even though it's a *single* if and only one more filesystem hit.

Package1 likes PEAR_Errors. It sets (pushes) the error mode to PEAR_ERROR_RETURN. It uses an instance of Package3 which then has an error. Package3 makes a call as such:

you can't, $var is deprecated

You can, see above.

Justin, please don't take this the wrong way but you should really take some time to try PHP 5 and understand the differences and why you can't do a PHP 5 package to work on PHP 4 nor include PHP 4 packages. In short there is no PHP 5 class compatible with PHP 4. If you wish a free PHP 5 hosting I would be able to help, for testing or anything you need.

I can set it up myself on my own server if I wish, but I don't want all of my current code to break. And even if I don't use E_STRICT, I don't need the extra testing and such it could take for now. I just don't need the extra functionality as of now. 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.

Cheers David Costa

-- paperCrane <Justin Patrin>