Re: exceptions

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