Re: Standardized way of interpolating variables into PEAR_Exceptionmessages?

Alan Langford wrote: > One of the problems with most error/exception mechanisms is that they > have a real inclination to take all the semantically meaningful data, > jam it into an unparsable string, and pass it back as an error message. > > The other major problem is that exceptions tend to get repackaged as > they go up the call stack to the originating application, and in many > cases the last traces of the original semantic information are lost as > the error message gets replaced by a higher level message. PEAR_Exception allows passing in a "cause" of the exception, which is to say you can pass in either a PEAR_Exception or a PEAR_ErrorStack array, and the information will be propagated up, just as PEAR_ErrorStack allows a "re-packaged" error. As the author of PEAR_ErrorStack, and a heavy user of PEAR_Error (by necessity as maintainer of the PEAR package), PEAR_ErrorStack, and PEAR_Exception, I think I can give a fair appraisal of when their use is appropriate and the advantages/drawbacks: PHP 4: 1) for situations where you want to force error handling and the errors are simple, use PEAR_Error - it has all the advantages of exceptions. 2) for situations where you need to group many errors, or want to make your application flexible in the switch to PHP 5, use PEAR_ErrorStack PHP 5: 1) for any error situation that involves propagating errors up to an unknown parent (i.e. outside the package), use PEAR_Exception. period. 2) for any fuzzy situation where multiple errors can occur, or warnings can occur without actual errors, use PEAR_ErrorStack. an example of multiple errors is in the PEAR package. Parsing package.xml is incredibly complex, and grouping all of these errors together is simple when using PEAR_ErrorStack, and very, very difficult when using PEAR_Error or PEAR_Exception. In short, my opinion is that we should let PEAR_Error go away for PHP 5, exceptions are just plain better and with PEAR_Exception do everything PEAR_Error can do and much more. I still find uses for PEAR_ErrorStack, but mandating rules about how to use it would be counter-productive at best, and downright annoying. Remember: PEAR_ErrorStack was written when PHP 5.0 was in alpha stage, as an attempt to solve problems and ease the transition to PHP 5. This was misguided, I think, but the problems that are best suited to PEAR_ErrorStack are obvious. If you find exceptions making it hard to solve a problem, take a look at PEAR_ErrorStack, perhaps you need a different tool. Rather than argue over PEAR_Exception/PEAR_Error/PEAR_ErrorStack, perhaps we could discuss improving the website, and especially the documentation, which is confusing and outdated. Let me be clear though: the work we're all doing on our respective packages is all-important (a la HTML_QuickForm2), I am only suggesting minimally redirecting the energy in this thread to tasks that really need serious attention. Thanks, Greg