Re: [PEPr] -1 for RFC::Error Handling Guidelines for PHP5 packages

Greg Beaver wrote:

Hans L wrote:

I tend to agree that classes shouldn't have to implement their own subclasses if they don't want to; however, I recognize that catching package-specific errors is only possible if your package has its own exception subclass. How do you propose catching package specific errors? Maybe that's simply not essential, but it would certainly be useful.

It is essential. The only other way to do this is to have a member that defines the context or package (this is how PEAR_ErrorStack works). Without this information, it is very difficult to process the error in any way other than to simply log it or exit the program. Many error conditions need to be reported to different users in different ways. 1) different languages 2) different level of detail Without both package differentiation and error type, translating error messages is exceptionally difficult. How would you translate: "Error in fire.tpl template, missing parameter 3" if you don't know that the 3rd word will be the name of a template? Any generic translation would simply incorrectly translate fire into the native language. If you wish to provide less detail for mid-level users as in "There was an internal error in the fire.tpl template, please try again later" and more for admins (the more detailed template error example above), this is impossible without knowledge of how the error is structured. PEAR_ErrorStack, of course, recommends a separate array of parameters (like array('template' => 'fire.tpl')), but without knowledge of what the parameters mean, the information is useless. So, basically, package-specific errors is not only essential, anything that does not provide it will be no more advanced than trigger_error() with fancy wrapping paper.

Let me just add that, for Exceptions, the structuring can be a nudge more evolved than arrays of parameters. Exceptions are classes, and so can have any fields deemed necessary to describe the specific error they define. It's the same kind of information, defined in a more syntax-correct fashion. I like the idea of user-oriented and developer-oriented messages. Perhaps this can be integrated into PEAR_Exception. Maybe two different toString methods, or a toString method with a level parameter, defaulting to developer-oriented messages (so that an uncaught exception shows full debug info, but a caught exception can be used as the source for the user error message).

It is essential elements such as these concepts that are also missing from PEAR_Exception.

PEAR_Exception needs work, naturally. It's under development. I reinforce, however, that the specifics of PEAR_Exception are not essential for defining the coding guidelines. Discussion and contributions to PEAR_Exception are important in parallel or after the approval of coding guidelines.

Incidentally, PEAR_ErrorStack has been around for plenty of time to have read the documentation and to have both tried it out and discovered how to use it alongside exceptions with no pain in performance or disturbance to the natural use of exceptions. To claim it is "too recent" is well, just not true unless "too recent" really means "too much effort to actually take the 1 hour it takes to read the docs and start experimenting with it." That is something I can't do much about :).

I may have sounded too harsh (I tend to, in written form). I did read PEAR_ErrorStack code and docs, and played with it a bit (it took more than an hour ;-). I hope that this much has surfaced from my comments in the discussion leading to this RFC. I have, however, never used it in any of my packages, so I abstained from talking a lot about it (I don't like talking about subjects I'm not very secure about). My veredict on PEAR_ErrorStack is simple: It's an excellent class, but designed under the constraints of PHP4. We can get a cleaner design out for PHP5. PEAR_ErrorStack contains some features that duplicate stuff already present in the base PHP Exception (like error callbacks, or setting up error catchers), and other features that are more adapted to Warnings (like error levels). A clean separation of warning treatment vs error treatment is something I tried very hard to write into the RFC. I hope the energy currently going into this discussion pours into discussing warnings. Here, Greg, I think you'll add immense value by taking a lead role in forming the standard. Cheers, Sérgio

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