Re: exceptions

Lukas Smith wrote:

Justin Patrin wrote:

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.).

Sounds like a lot of work with handlers. Essentially what we want is to differentiate between how the errors are handled inside the package and how they are leaked to the outside. Very tricky. I fear that this could only be done if we know where a given call originated and where we are within the current call stack so that we know when to convert whatever style was used internally to what the user actually requested. I dont know how to do this atm. regards, Lukas Smith smith@backendmedia.com _______________________________ BackendMedia www.backendmedia.com berlin@backendmedia.com Linn Zwoch Smith GbR Pariser Str. 44 D-10707 Berlin Tel +49 30 83 22 50 00 Fax +49 30 83 22 50 07

I don't see how what I proposed doesn't fix the problem. If an intermediate package is checking for errors from a package that it uses, it has to deal with re-raising the error already. In this case, you pretty much lose the stack data unless the package puts the original error in as userdata, or re-makes the error. Yes, this is a bit messy, but if a package is checking for errors, it has to deal with this on its own usually. IMHO, most lower level errors are simply passed up the stack, but maybe I haven't looked at enough PEAR code to know. How about this then: PEAR_Error extends Exception The PEAR_Error could be thrown *as it is* without having to convert between it and some PEAR_Exception. If this is impossible (or hard to do) please tell me. I haven't done any exception handling in PHP yet as I am forced to stick with stable (and mature) versions of PHP for my work. -- paperCrane <Justin Patrin>