Re: exceptions

Hans Lellelid wrote:

Lukas Smith wrote:

Jackson Miller wrote:

On Tuesday 08 June 2004 13:11, Justin Patrin wrote:

This is exactly the kind of thing that I was thinking. You set PEAR_ERROR_RETURN or PEAR_ERROR_EXCEPTION. If the coder selectes exceptions, they get them *instead of* PEAR_Errors. Either should work.

Would that work? Aren't there PEAR modules that check for errors or cascade errors

back up?    How could that be done with either error objects or exceptions?

yup this is where I see the problem

Yeah, you're right; this is a problem. Perhaps there isn't a single solution like this that'll work. When package X using package Y upgrades to use PHP5 it may need to still check for PEAR_Error returns from package Y, and possibly wrap & throw these as Exceptions (if package X chooses to use exceptions). There doesn't seem to be a very smooth migration path from PEAR_Error -> Exceptions. If a class stands alone (doesn't rely on any other packages) then the raiseError() method would work (or half work, or whatever). Hans

The solution I proposed should still work. Here's my thoughts. When raiseError (or perhaps new PEAR_Error...some packages use it I think) is called, PEAR decides, based on the configuration, whether to create a PEAR_Error (and call the error handling function or return it) or whether to throw an exception. If the exception is thrown, it goes right back where it would have gone if the PEAR package threw the exception, with one extra layer in the call stack. But what if a package which uses another expects a certain type or error handling? Well, it can set the error handling as it wishes (pushErrorHandling), then catch its errors, then put the error handling back (popErrorHandling). Then, if it decided to throw an error, it uses raiseError and the caller gets what *they* wanted (RETURN, EXCEPTION, etc.). -- paperCrane <Justin Patrin>