Re: PEAR Coding Standards

It would be nice if the introduction to PEAR_ErrorStack made a fair and level comparison, I've not had time to judge in detail the pro/cons of PEAR_Error vs PEAR_ErrorStack. This is the current introduction from the manual, and at present, doesnt help explain why it should be considered over PEAR_Error.. *

     Fully unit-tested and documented
     ** is this really a selling point - isnt all of pear supposed to
     be like this????

*

     blazingly fast - blows PEAR_Error out of the water
     ** why - shouldnt we sort this out for PEAR_Error

*

     Package-specific errors
     ** you can do this by creating Package Error Objects, that wrap
     PEAR_Error

*

     Error levels (notice/warning/error/exception)
     ** This may be a selling point, although it could be done kludgly
     with $userinfo in PEAR_ERROR..

*

     Error context data is saved separate from error message
     ** not sure what the benifit of this is.

*

     Error cascading - parent errors can be specified
     ** not sure what the benifit of this is.

*

     Dynamic error message generation allows generation of multiple and
     distinct error messages from the same error object
     ** not sure what the benifit of this is. = does this hint at
     translations? - in which case its supported by Package Error
     Objects, that wrap PEAR_Error

*

     Sophisticated callbacks are available for error message
     generation, error context generation, and error handling
     functionality, ...
     ** not sure what the benifit of this is.

Regards Alan

Check out PEAR/ErrorStack.php. Since we're on the subject of errors and coding standards, seems like it might be time to update the coding standards to mention that all new packages should be built using ErrorStack instead of PEAR_Error. Yes? BTW -- Greg, correct me if I'm wrong -- but I believe my SVN package is a good example of using ErrorStack instead of PEAR_Error in a package. http://www.killersoft.com/packages/example_tree.php -Clay