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

And to directly answr your question, this only takes one more if statement in raiseError. If error handling is set to PEAR_ERROR_EXCEPTION, throw it. Here's my logic. If a package is trying to handle errors from a package it uses, it has to use pushErrorHandling already as it doesn't knwo for sure how the user has set it. If the user sets PEAR_ERROR_DIE, but the package wants it to return so *it* can handle it, it pushes its own handling, handles errors, then pops its error handling back off so the user (or higher level package) gets its errors as it wanted them. -- paperCrane <Justin Patrin>