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

Greg Beaver wrote:

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.

This is a skew. You are viewing Errors as top-severity warnings, or the complementary, Warnings as probable errors. I stick to my definition; it is correct. Let me try to defend it, framing it in your reference. An Error is a condition from where you can't recover. You can read this as being unable to recover in 100% of the cases. If it isn't 100%, then it isn't an error. A Warning is a condition you suspect isn't correct, but from which you can recover. However, its entirely possible that a warning will produce unexpected behaviour -- a bug -- or create conditions for an error. The major difference between errors and warnings is that errors suspend execution, while warnings don't. Its a direct result of the definition.

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?

Nobody questions the need to log/notify warnings. But what you're talking about here are warnings (they don't suspend execution), not errors.

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.

Naturally, the warning would have been logged. As its a warning, execution would continue, and you would get a package -- along probably, with warnings spit out on stderr.

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.

Keep an open mind and a lot of patience. We have close enough opinions for a middle ground to be reached. More, I think we're only disagreeing on semantics. Cheers, Sérgio

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