Re: Re: PEAR_Warning proof of concept

Hi Sergio, Sergio Carvalho wrote:

I agree. Exceptions and warnings are different. I have already wrote about that in the wiki, while commenting Greg's entries.

Yes, I saw those afterwards. Good notes.

The best system I imagine right now would be for PEAR Exceptions to be quite bare, and based off PHP Exceptions, while adding these properties: 1) Single hierarchy root. All exceptions descend from PEAR_Exception, so you can easily all errors at the top-level. 2) Support rewrapping, or exception nesting so we can disallow rethrowing of exceptions.

I don't think re-throwing should be disallowed. It should definitely be discouraged, though. In almost all cases wrapping makes most sense, but I could imagine some scenarios where you just want to log a message and then let the exception coninue on. (Does the file/line information really ge reset when you re-throw? I'm too lazy to check this immediately.)

3) Work closely with PEAR_Warning (I don't know if this exists), for the common operations of demotion and promotion to/from warnings.

Yeah, in my vesion this is as simple as: // conversion to exception $warning = array_pop(somestack::getWarnings()); throw $warning; // converstion to warning } catch (SomeException $se) { somestack::pushWarning($se); }

4) Provide a throwing/filtering method so it is possible to silence specific subclasses of PEAR_Exception.

I have a hard time with this requirement, mostly because it feels like a kludgy solution to faciliate sloppy coding. Do people really disable error handling while developing? I have never done this & just in general feel that PHP provides *plenty* of RAD features for developers. Generally I find that I like error handling to be *more* verbose during development than less. Exceptions provide much better context than PEAR_Error so hopefully the point of disabling error handling altogether will be removed, since it will (IMO) be much easier to *fix* the errors themselves. Implementing a workaround for a built-in language feature -- i.e. throw() -- for such a questionable purpose just seems like a bad idea.

Namely, Exceptions don't have to support severity levels, or publisher/subscriber patterns. These sit rather well in a warning class.

Well, while I agree, I think that it's fine to have the basic observer support in PEAR_Exception. I think some people will want to "keep track" of exceptions that are thrown in some sort of unified way. I think it runs contrary to the 'deferred' nature of exception interpretation, but I also think that PEAR developers have been doing things the other way around for too long to just change overnight. Basically, IMO it doesn't really hurt to allow observers in PEAR_Exception. Perhaps people will find that they don't need them in practice. Cheers, Hans