Re: Re: PEAR_Exception in CVS

Greg Beaver wrote:

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 :).

True, but from my perspective this code is not designed to handle warnings or notices. This is *error handling* code. There are many options for warnings or notices -- including, sure, PEAR_ErrorStack. In the Java world you have methods like getWarnings() or hasWarnings() which seem rather similar to how PEAR_ErrorStack works. Personally, I think that's overkill. All I've ever wanted to do with warnings or notices is log them, so I think that standardizing on something like trigger_error() makes perfect sense.

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.

I don't see in this case what PEAR_ErrorStack provides besides a convention. I.e. why not say: "If your class has warnings or notices you must implement ILogger interface which declares setLogger(Log $log) and log() methods to use for these notices or warnings." Or make PEAR_ErrorStack simply an interface (e.g. ILikeToComplain) that establishes getWarnings() and getNotices() methods. Personally, I think the logger would provide for a more automated solution. Especially given the ability to add listeners to loggers. I'm fine with any of these ideas. I think that having a prescribed system for notices and warnings would be a good thing. Anything that needs to be *handled*, however, should use an Exception; it's what they're built for. Hans