Re: Try Catch
| From: | Tomas V.V.Cox | Date: | Tue, 24 Jul 2001 12:54:39 +0000 |
| Subject: | Re: Try Catch | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-1021@lists.php.net to get a copy of this message | ||
"Stig S. Bakken" wrote:
>
> "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? :-)
We are in the way :). To keep things more simple, please test this
script:
<?php
require 'DB.php';
PEAR::setErrorHandling(PEAR_ERROR_DIE);
$db = DB::connect('pgsql://postgres@localhost/bd');
$id = $db->nextID('non_existant_seq', false);
echo "Hehehe, I'm still alive and you have a bug";
?>
Tomas V.V.Cox