Re: RE : [PEAR-DEV] Mod 10 for Payment package?

Hi Stefan, Stefan Neufeind wrote:

Hey Greg, please calm down a bit :-)))

I don't think you can see my tongue in cheek over the internet very well :). I'm quite calm, I assure you.

In general using pear-error-objects would be good, I agree with you. But we have to keep in mind the (large?) overhead it produces.

Just to give an idea, I get a varying overhead of about 0.0014 to 0.0022 seconds on every raiseError() call, depending on the function depth. Most of this overhead is from debug_backtrace(). isError() is negligible, more like 0.0001 seconds. The largest overhead is from require_once 'PEAR.php'; I think it should be recommended to use is_a() over PEAR::isError() in all packages, and those that need PHP < 4.2 compat (virtually all) can simply add in a if (!function_exists('is_a')) { function is_a($obj, $classname) {

    return get_class($obj) == strtolower($classname) || is_subclass_of($obj, $classname);

} } somewhere in the file. In this way, the only need to include PEAR is if an error needs to be raised, for packages that need fast loadup times. However, for Validate's case, there need be no overhead at all: if (error condition) {

    return Validate::raiseError(...)

} function raiseError(...) {

    include_once 'PEAR.php';
    return PEAR::raiseError(...);

} Basically, if PEAR_Error is too much overhead, then it needs to be scrapped completely in favor of another system. I could see only one other possibility, the use of a global error stack which is accessed using functions. This system wouldn't affect error raising or advanced error handling systems. so instead of using PEAR::isError($retvalue), one would simply check for an error like this: $result = $somepackage->thingthatreturns(); if (PEAR_hasErrors()) {

    // handle them or return the exception case
    $err = PEAR_getError(); // or PEAR_popError();

} In this way, packages that don't need to handle errors wouldn't be forced to. Regards, Greg