Re: Re: PEAR_Exception in CVS

Hans Lellelid wrote:

But in general, Exceptions provide a very flexible (superior!) error-handling approach that can (should!) be used for any & all errors (but not 'warnings' or 'notices').

(Warning: strong views about to be expressed) This little parenthetical statement "(but not 'warnings' or 'notices')" is the essence of why I am very apprehensive about the sudden rush to PEAR_Exception. The code Hans and Tomas has designed does not allow any for any way to express a notice, warning or other condition, except to throw a PEAR_Exception. Users WILL do this - they use PEAR_Error for it already. This means any unhandled warnings/notices will cause fatal errors. Since all possible error conditions do not trigger the first few times you run an application, this means any package that does this will be instantly unstable and unsuitable for production usage. The QA nightmare is something I will not be responsible for :). The only alternative is to both throw exceptions AND use trigger_error or some other hack like $this->log(). Already, logging will require some custom interface hacks. None of these choices matter until you start combining components. If one system uses trigger_error() for warnings/notices, and another uses $this->log() and another uses _global_log() and another uses $this->debug() for debug and $this->log() for warnings/notices, you end up with a complete and totally useless mess of untraceable informational notices when you turn on debugging. Have ANY of you read the introduction to PEAR_ErrorStack? I don't claim the solution I've written is the best, but the problems stated there MUST NOT BE IGNORED. Thank you, Greg