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

Justin Patrin wrote:

I disagree. The RFC defines errors specifically so that they can be separated from warnings. But that's a simple semantic issue that has nothing to do with what I was talking about. Warnings *will* be handled differently from errors (exceptions). Therefore, it should be handled in a different RFC.

Warnings *are* potentially error conditions, usually they are errors that are too complex for a deterministic program to evaluate as to their severity. Therefore the deterministic definition of an "error" in the "Error Handling Guidelines for PHP5" is completely inaccurate. From the end-user's perspective, if you don't notify them of an error condition, you've got a bug. They don't care whether it is an error in every situation, or just in 5% of the situations. In several years of developing phpDocumentor, the majority of bug reports and support requests came from edge cases, where we had not properly handled an error condition that only rarely is actually an error condition. Every case would fall outside of the context of errors as defined by the RFC. What use is an RFC that doesn't account for the majority of tricky bugs? For example, in packaging, if you specify a php dep with name php, it is a warning. You may have meant to do a pkg dep with package name php, and there is no way to detect whether this is the case. The name php is simply ignored, however, as it has no negative or positive effect on things. Listen, I've already voted +0, not -1. Also, I have a very good memory, and repeating arguments that have already been said on the list will not change my mind, as I have already considered them carefully. Greg