Re: PEAR_ErrorStack renaming question

Hi, I understand you're saying that PEAR_ErrorStack should continue as an error handling for PHP4, while being extended so it can easily transform non-fatal errors into warnings in mixed PHP4/5 environments. I'd like to clarify that I find this a-ok. When I proposed that PEAR_ErrorStack should be renamed, I was doing so in the context of pure PHP5 environments. I do so, because PEAR_ErrorStack closely matches the set of features required for a warning handling class. However, in this environment (pure PHP5) it makes no sense to have a PEAR_ErrorStack, since errors are handled by exceptions. The warning handling class should be named PEAR_Warning. In other words, I'm saying that I believe once the requirements for a PEAR_Warning class are defined, we'll find out most of them can be implemented with code lifted from PEAR_ErrorStack. However, the first step in this direction is clearly defining the API of the PEAR_Warning class. You have a very good grasp of these concepts. Do you think you could launch the discussion with draft requirements and API spec? An email will do. If the discussion is too confuse in the list, it can then be moved to a wiki. Having said the important part, Greg, you'll excuse me for nitpicking a bit: Please don't say stuff like "transaction-style error aggregation" when referring to PHP5 environments. You probably mean "transaction-style warning aggregation". Errors are fatal until they're handled, and by then they become warnings. You can only aggregate warnings. Cheers, Sérgio Carvalho Greg Beaver wrote:

Hi all, Because PEAR_ErrorStack is most useful for php4 error handling, and bridging the gap between error handling in php4 to php5 exceptions, I don't think changing the name will be a good idea. If we have a document that says you gotta use exceptions (and we do), there may be some confusion, but I would be surprised. Besides, who are we to tell developers outside of PEAR how they should code? We should control the code *inside* PEAR and let others do whatever they please. PEAR_ErrorStack is a stack-based implementation for storing error conditions. Having said all of this, I think the current stack implementation needs some work, but not for the reasons given on the list. I will not engage in any polemical battles over the technical details, but will accept any good ideas :). My current thought is that it would be interesting to define a child class of PEAR_Exception named PEAR_Warning whose sole purpose would be to allow a transaction-style error aggregation. By this I mean that PEAR_Warning would have a method that says "start noticing non-fatal errors" and from this point on, any warning that is registered through its monitoring of PEAR_ErrorStack *and* the use of PEAR_Warning::add() (name is negotiable) would be simply placed into a holding array. When the method that says "stop noticing non-fatal errors" is called, a PEAR_Exception can easily be created with the PEAR_Warning as a cause, and all of the warnings would be clearly and easily delineated by where they came from. This would ultimately make PEAR_ErrorStack only useful in the transition from php4 to php5, and that was its original intent anyways :). In any case, I would appreciate it if people hold off on the standard positive and negative critiques until they see the code I'm talking about, it should be very short code. Greg

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