Re: Try Catch

"Tomas V.V.Cox" wrote: > > "Stig S. Bakken" wrote: > > > > "Tomas V.V.Cox" wrote: > > > > > > Yeah, good idea, but still have one problem. Think for example in the > > > nextID problem: > > > > > > $this->pushEH(RETURN); > > > $err = $db->query(); > > > $this->popEH(); > > > do { > > > [...] > > > } while ($repeat): > > > > > > // at this time we return the error, but don't > > > // do action as they ocurrs at object creation time > > > if (DB::isError($err)) { > > > return $err; > > > } > > > [...] > > > > > > We need an extra function to "re-trigger" errors, this is: do the > > > actions with the data contained in the error. I though on: a new PEAR > > > method for ex: raiseErrorObject($obj), but now I can imagine also a > > > PEAR_Error::raiseError. > > > > > > 1) return $this->raiseErrorObject($err); > > > 2) return $err->raiseError(); > > > > > > Clear not? :) > > > > Not to me at least :-) > > > > What do you mean with "re-triggering" errors? The actions with what > > data contained in what error? :-) > > > > Umm... if I set a error handler (say DIE), I expect that the program > dies on error, this is the coolest thing of the setErrorHandling. In the > situation I told, the error object is built and then _only_ returned. We > are doing now: disable the handler with the stack, call the function, > get the error, enable the handler back and return the error back to the > user. But the user expects that the error forces the app to die and it > don't do it. > > User: > PEAR::setErroHanlding(PEAR_ERROR_DIE); > $db = DB::connect(); > $db->nextID('myseq'); > > Devel: > function nextID() { > // disable handler > $error = $db->createSequence(); > //enable handler > if (DB::isError($error)) { > return $error; > } > } > > See it? The error is returned while the user expects the app to die. So > we need something to return the error but via raiseError. We could do: > > return $this->raiseError('create sequence fail!'); > > but is better to return the real error contained in the $error obj, as I > proposed above. > > Hope that this time I can express the idea in a better way :) Okay, I think I understand what you're saying. If the "pear user" sets an error handler, he expects it to be used in all cases. But for example in the case of nextId automatically creating the sequence, the user would get an unexpected error because it "forces" errors to detect something. But when some code pushes/pops an error handler, it needs to be aware of which errors may occur when the temporary error handler is in effect, so it can "re-throw" if necessary. This again means that it's very important to document all possible errors. Or did I misunderstand you again? :-) - Stig