Re: Try Catch
| From: | Tomas V.V.Cox | Date: | Sat, 21 Jul 2001 22:55:01 +0000 |
| Subject: | Re: Try Catch | ||
| References: | 1 2 3 4 5 6 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-943@lists.php.net to get a copy of this message | ||
"Stig S. Bakken" wrote:
>
> Oleg Rekutin wrote:
> >
> > That should be the case, I think. I would consider the current callback-
> > related problem with nextID/createSequence a bug.
>
> Agreed. Will fix.
>
This problem could (and probably others in the future) solved having a
way to differentiate if error objects should or not use selected error
handler instead of PEAR_ERROR_RETURN.
Some situations and posible solutions:
* The user's point of view:
//universal error handler
PEAR::setErrorHandling()
// per class handler
$db->setErrorHandling()
* The Pear developer point of view:
1) Classes that use other classes:
class foo {
function fooBar() {
$db = new DB_Bar;
// always must be present
$db->setErrorHandling(PEAR_ERROR_RETURN);
$this->db->query();
}
}
2) Public methods calling private methods inside the same class:
funtion do() {
$error = $this->_query();
if (PEAR::isError($error)) {
// raise the created error object
return $this->raiseErrorObj($error);
}
}
function _query() {
if (!mysql_query()) {
// never use raiseError
return new PEAR_Error('fail!');
}
}
3) Public methods calling public methods inside the same class:
$this->errorHandlerDisable();
$error = $this->query();
$this->errorHandlerRestore();
if (PEAR::isError($error)) {
$this->fooDelete();
return $this->raiseErrorObj($error);
}
More intelligent ideas?
Tomas V.V.Cox
PS.-method names are only for ilustrating the idea