Re: PEAR_Warning proof of concept

Tomas V.V.Cox wrote:

Hi Greg, At the same time of you, was thinking/coding in Warnings too, excuse me for that. I took a different approach than you, maybe we can exchange ideas. For me warnings are: 1) Non fatal 2) Non "returnable" 3) Not objects (too big and slow for handling a big ammount of warnings) 4) Easily avaible mechanism (that's why I've put the code in PEAR_Exception)

How dare you think too! ;) add 5) Easily promotable to exceptions - noting the original source 6) Easily filtered by severity 7) Easily traceable the same way exceptions are Think of error_reporting(E_ALL & ~E_NOTICE) - this is very useful in terms of allowing warnings to appear on a devel server only. I think #7 brings #3 into question, as the only way to easily trace something is a debug_backtrace() call. Has anyone does a test on how slow "new Exception('msg')" is compared to creating the array and doing a debug_backtrace()? Or, how slow it is compared to creating the array? These would be useful numbers to have. I don't understand what you mean by #2. #5 can be handled best with PEAR_Exception's easy nestable exceptions, which is why I designed my proof-of-concept as an extended object. If it is too slow, that is an issue. Perhaps the better solution is a compromise (also drawing on Alan's message). If warnings are only instantiated as objects if they are within the desired error level, but observers are passed the warning message for logging purposes, this will speed things up dramatically. It would mean that for development purposes, warning error level can be set to a point where warning objects are instantiated to take full advantage of PEAR_Exception's features, but on the production server, warnings are only logged. Obviously, the error reporting level could be set for each package if warnings could be promoted to exceptions for a low-level package. This would be possible by making the error level a private static, so that each extended warning class can simply redefine the error level accessors if needed. <?php // assume PEAR_Warning is simply an extension of PEAR_Exception for namespacing purposes class MyPackage_Warning extends PEAR_Warning { private static $_errorLevel = 3; public function setErrorLevel($level) {

    self::$_errorLevel = $level;

} public function getErrorLevel() {

    return self::$_errorLevel;

} } ?> Another alternative that would allow blank classes is: <?php class PEAR_Exception_Errorlevel extends PEAR_Exception{} class PEAR_Warning extends PEAR_Exception { private static $_errorLevel = array('PEAR_Warning' => 3); public function setErrorLevel($level, $class) {

    if (class_exists($class)) {
        self::$_errorLevel[$class] = $level;
    } else {
        throw new PEAR_Exception_Errorlevel("Warning class '$class' does not exist");
    }

} public function getErrorLevel($class) {

    if (class_exists($class)) {
        if (!isset(self::$_errorLevel[$class])) {
            self::addWarning("Warning class '$class' does not exist");
            return 0;
        } else {
            return self::$_errorLevel[$class];
        }
    } else {
        throw new PEAR_Exception_Errorlevel("Warning class '$class' does not exist");
    }

} } Greg