Re: Exceptions was Basic DB/MDB Question

On Wed, 23 Mar 2005 12:10:02 +1100, Dan Rossi <pear@electroteque.org> wrote: > > On 23/03/2005, at 11:41 AM, Greg Beaver wrote: > > > > > > <?php > > require_once 'PEAR/ErrorStack.php'; > > function useErrorStack($err) > > { > > PEAR_ErrorStack::staticPush('PEAR_Error', 'error', > > array('olderror' => $err), $err->getMessage()); > > } > > > > PEAR::setErrorHandling(PEAR_ERROR_CALLBACK, 'useErrorStack'); > > ?> > > > > > > > > Thanks I'll give this a shot. I personally have to side with Lukas, > doing try/catch all over the place slows down development on > prototyping. There are however UML modelling software in the midst. And > I have had discussions with c++ developers on this, adding the > exception code while you are coding however helps debugging later on, > rather than going back and having to add them all in later. Which is > how I feel errorStack which uses exceptions may be a better option but > I am gonna try this out. > Dan, I suggest you check the pear-dev archives for the *extensive* discussion on Exceptions there. I was a big proponent of sticking with returns for a while but I was won over. There's also an RFC which many of us helped to write. I think you have a fundamental misunderstanding of the different error types here. You can code for error returns or for exceptions, but you can't just up and switch from one to the other. The paradigms are fundamentally different. As an example, think of Exceptions bubbling up vs. errors returned. If you code for returns but instead get bubbling up youre code is going ot behave unpredictably. The same is true for the opposite. If you code for returns and switch to exceptions you're going to end up with a lot of stupid try / catch / throw blocks which essentially do nothing. Exceptions should go straight to the code which will deal with them. errorStack doesn't "use exceptions". It has some options for exceptions, but I wouldn't say it "uses exceptions". It uses whatever error type you tell it to use (Exceptions, PEAR_Errors, arrays, etc). If you want to be able to silence your errors, comment out your throw statements. This is essentially what you do when you ignore error returns (yes, I know it's a *bit* different, but not by much). -- Justin Patrin