Re: Re: cvs: pear-core /PEAR

Sergio Carvalho wrote:

Alan Knowles wrote:

I think what became clear after you had implemented it, was that you had attempted to catch warnings. - by coding around the fact that you couldnt use try/catch. What I was trying to illustrate was that you should _never_ expect to catch warnings, - Warnings should be prevented by a) sending the correct data to a method (eg. testing your input) b) calling some 'test' method prior to calling the method. (eg. a method to help you test your input) c) telling the method that you explicitly know it may have a non-critical failure, and instructing it not to warn you. I could not see any event that did not fit into those situations, that should not be an exception. (and exceptions can be carefully designed not to break the stack, by carefully placing try/catch and rethrowing.)

Hmm, I can see how this warning discussion can get really interesting. This is potentially a nice idea. If I read you correctly, you'd do something like: PEAR_Warning::allow('Some_Package_Downcast'); Some_Package_Class::method(); And then, inside the method, you'd have the regular PEAR_Warning::add. If an unallowed warning is fired, it gets automatically upgraded to an exception, right?

err, it should be the other way around! but isnt this another case of where the exception backtrace will get "polluted" with non relevant data? seems like more and more this fact is becoming a show stopper (as it already was for the turn pear_errors into exceptions on demand php4/php5 compatibility thing). maybe its time we address this? regards, Lukas