Re: Re: cvs: pear-core /PEAR ErrorStack5.php Warning.php

I wish I had more time to look at it. The more I look at it, I get the feeling that if you need to pass information back to the caller, then perhaps it should have been using an exception. The idea of turning the Warning handler on/off to catch messages slaps of why arnt exceptions being used.. I suspect Warnings Should really be preventable by method arguments.. (either a extra arg 'dont warn me' / returning booleans - and logging only done to detect programming errors, rather than actually be dealt with. It reminds me a bit of a debugger in some respects.. I guess the big question is where does this fit in the equation of trigger_error("Some warning" E_USER_NOTICE); - an warning that should be preventable by checking args.. or telling the method that you know it might fail? throw PEAR_Exception() - a situation that is preventable by try()'ing. Regards Alan Greg Beaver wrote:

Alan Knowles wrote:

I was wondering if the WarningStack should actually be an observer of the Warning object. - that way under normal operation, you dont end up filling up memory with excessive amount of old warnings. The principle being, the Warning object would only store the last Warning, eg. $warn = PEAR_Warning::getLast(); or maybe $warn = PEAR_Warning::getLast('MyPackage'); (in which case it would store per/class/package warnings?) if you want to monitor warnings you would do something like: require_once 'PEAR/WarningStack.php'; PEAR_WarningStack::monitor(); I guess that would mean the 'standalone' method would be a little simpler. Reards Alan

Hi, Possibly, but I think with the current system (no warnings will be stored at all unless you're looking for them) it might be even better. What do you think? Greg