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

Hans L wrote:

Pepr wrote:

But: "It was written to cope with Exceptions, introduced in Zend Engine 2 as the error handling mechanism." -1 from here, I do not like the idea to force the usage of exceptions as general errors hanlders. I failed to see why each single package should declare (or extends, or...) their exception classes. Why? I can imagine some without any kind of exceptions...

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. It is essential elements such as these concepts that are also missing from PEAR_Exception. 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 :). Greg