Re: PEAR DB examples?

> On Sat, 9 Sep 2000, Stig S. Bakken wrote: > > | On Fri, 8 Sep 2000, Sterling Hughes wrote: > | > | | Perhaps we could have a register_error_function method: > | | > | | function error ($obj) { > | | die(sprintf("Error [%d]: %s", > | | $obj->getCode(), $obj->getMessage())); > | | } > | | > | | $dbh->register_error_function("error"); > | | > | | // .. Normal stuff, the error function will be called on error. No need to > | | check > | > | I've been pondering a bit on this one, and the solution that I find the > | most appealing is the one you suggest. Examples: > | > | $dbh->setErrorHandling(PEAR_ERROR_RETURN); > | $dbh->setErrorHandling(PEAR_ERROR_PRINT); > | $dbh->setErrorHandling(PEAR_ERROR_TRIGGER); > | $dbh->setErrorHandling(PEAR_ERROR_TRIGGER, E_USER_WARNING); > | $dbh->setErrorHandling(PEAR_ERROR_TRIGGER, E_USER_ERROR); > | $dbh->setErrorHandling(PEAR_ERROR_DIE); > | $dbh->setErrorHandling(PEAR_ERROR_CALLBACK, "error_function"); > | $dbh->setErrorHandling(PEAR_ERROR_CALLBACK, array(&$obj, "error_method")); > > I just implemented this in DB_common. All errors from DB objects are now > created with $this->raiseError() instead of new DB_Error(). > setErrorHandling is implemented as per the examples above. It's backward > compatible and everything. > > If this solution makes people happy, I think it would make sense to move > the setErrorHandling and raiseError methods into the PEAR class. > The problem is that not all the classes inherit from the PEAR class, DB doesn't, neither does File_Find. So we'd have to change that before making the move. Sterling