Re: Re: cvs: pear-core /PEAR

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?

Anything else, lower than that is debugging code, which needs a debug callback or logger, rather than a warning.

Just for reference, how'd you allow the case presented in the incomplete recovery, in the Exception Wiki? That's the third code snippet in this section: http://wiki.ciaweb.net/yawiki/index.php?area=PEAR_Dev&page=RfcExceptionUse#toc32

I think previous examples of trigger_error as a crappy error handling mechanisim, was more to do with their use where exceptions now should be used.

PEAR is object-oriented, so I guess plain trigger_error is out of the question. Cheers, Sérgio

Regards Alan

Greg

Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc