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

Hi Greg, Greg Beaver wrote:

Hans L wrote:

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

I agree that adding context for errors is extremely useful for understanding errors; and certainly that manifests itself in those two situations (and more).

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.

less relatedly ... Yeah, that opens up a huge can of worms. I think the translated stuff would be useful to the *person* doing the translation, but I wouldn't ever rely on machine translation of errors. Language grammar is just a start; then of course there are the cultural/sociolinguistic aspects of the audience, etc. Fun stuff.

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

I don't really see a need for context in PEAR_Exception. Or rather, I don't think this level of context should be forced. Context differs so much, as you point out, that each class could have a very different interpretation of what context means. E.g. in Phing you have a location object that is passed as context for all errors. This object contains the location (line num & offset) of the Expat XML parser in the main build XML file when the exception was thrown. Extremely useful within Phing, but would be worthless to any calling app that didn't know about this. So, basically, *I* feel that while PEAR_Exception could be extended to accept yet another parameter, exception subclasses coudl also provide their own context property(ies) & methods, e.g.: catch (SQLException $sql) { $sqle->getSqlStatement(); // the statement that triggered the error $sqle->getNativeError(); // native RDBMS error // etc. you can probably imagine other relevant contexts here. } Of course, for other packages, context may be largely irrelevant.

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 :).

Yes, this is true. I think that Sergio simply meant that it doesn't have a wide usage base yet in PEAR -- so people don't really know how to fit it into the picture. Personally, I like using stacks for warnings (and not errors), so I will use PEAR_ErrorStack (PEAR_WarningStack) for handling all of my warnings & notices. I would probably set it up so that it would log my warnings for me automatically. I may also configure PEAR_Exception to have exceptions logged automatically (via observers), although I tend to like exerting more control over that (i.e. if I catch & appropriately handle an exception, I don't want it going into my log). I find the idea of explicitly logging caught exceptions turns out to be a very feasible task, since logging only happens in top-level blocks. While I'm at it, though, one thing that PEAR_Exception does need (last I looked) is appropriate display of the stack trace (which is not the same as nested exceptions, of course). -Hans