Re: Code Modifications Needed for Error Handling

Hans Lellelid wrote:

Davey wrote:

Now, what this means is, whether you use PEAR_Error or PEAR_Exception, assuming you don't try...catch your exceptions, all errors will end up on the PEAR_ErrorStack (great if you're mixing 4&5 code). However, if you do try...catch any exception, it will not go on the ErrorStack.

I think at this point this discussion is moot. That said, the problem that jumps out immediately when I read your suggestion is this: How do you deal with PHP5 packages that use other PHP5 packages and hence use try / catch blocks ... ? Remember that PEAR packages don't only raise errors; they also check errors raised by other packages. Certainly if I were writing a PHP5 package that depended on others, I'd want to be able to take advantage of try / catch to handle exceptions. Again, though, the RFC for Exceptions in PHP5 packages finished. Thankfully we can now move on to addressing warnings and other related issues.

To all: I missed this the first several times Davey posted, and it's an important distinction. Davey IS NOT trying to change anything with the RFC. He's talking about adding some forwards compatibility to PEAR that will work for both existing PHP4 packages and packages that wish to support both php4 and php5 with E_ALL. set_exception_handler(), for example, is only used for exceptions that slip through the cracks, PEAR_Error is used only in php4 packages. None of this applies to exceptions, but it does give a nice solution for using legacy packages in php5 alongside new ones. With that knowledge, it would be good to re-read what he's saying from a fresh perspective and see that it offers a good solution for those who will be mixing the new php5 packages with the older packages, and without any penalty to PHP5-only packages once the old packages are burned for warmth on a particularly cold day in Siberia. Greg