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

Sergio Carvalho wrote:

Greg Beaver wrote:

Sergio, I never intended a personal attack. However, I did not feel that the RFC addressed all of the concerns I did in fact raise in the comment period you spoke about. It should be clear by now that in fact there were a few people who were absolutely gung-ho about the original proposal, and the majority have some slight to large reservations.

But I did interpret as a personal attack. Out of all this mess, I came

I'm sorry that it came across this way, I'm still learning to temper strong opinions with obvious respect for the opponent of those opinions.

There are reservations, but in most of them I see some inexperience with exception usage, coupled with PEAR core class turf defence. Time and experience will soften these reservations, and that's why I'm so keen on the idea of alpha or beta RFCs.

This also seems the best solution to me.

Can you list the sections you feel are missing from the text? I aimed at writing a light text, and may have overcompensated. The idea of a light text is: a) Not to force PEAR developers to read huge manuals in order to comply with Coding Guidelines. Writing code is hard enough as it is, and we're not being paid here. b) Stick to pretty consentual stuff. The more restrictions are issued, the more controversy will be generated c) Impose little on the developers way. Hard, restrictive CG get ignored, or poorly followed. Its better a light CG, 100% used, than a complex CS where each dev chooses which 80% of the doc to follow.

I think that c is a very important point. I would be willing to work with you to develop a 1-paragraph version of the existing RFC, and a separate examples page that is referenced. Of course, if you would like a break, I understand that as well. Most of the missing things deal with at least mentioning the missing things that you feel should be specifically spelled out in another RFC, so that the gray areas are clearly not defined.

Sticking to these principles, please list the missing sections, and we can start work on that.

In fact, it does not even go into enough detail on how to name exceptions. With the current proposal, these are all allowed: - MyPackage_ExceptionSomeCondition - MyPackage_Exception_SomeCondition - MyPackage_Exception_Some_Condition

Do we have to define these? Won't we be overimposing on the developer? Remember that class naming is already covered by the current CG, so there's not much freedom left.

Perhaps amending the existing CG to say that it is not only allowed, but recommended that all exceptions be in file PackageName/Exception.php Both for ease of location and performance concerns. As you say, it need not be hard and fast, but a recommendation is in order.

The question of whether to recommend using error codes vs. class names is not addressed at all.

Yes it is. Error codes are deprecated by the RFC.

My fault - I re-read but missed this sentence in my re-reading.

It suggests raising warnings on the config example, but does not standardize this in any way. Do we expect our users to do this?

No. We expect to complement this RFC with a warning handling RFC. Warnings are more complex, and more prone to design discussions that exceptions. I postponed defining warnings, but the error handling RFC is dependant on the warning handling RFC.

I actually think that with warnings, design must lead the RFC. Only after a relatively stable and well-liked warnings design exists should the warnings RFC be written. However, this unfortunately also means that anyone who needs to use warnings should expect to possibly need to change their code.

After all this discussion, I hope someone else other than me will lead the Warning RFC. If this one was difficult to pass, a Warning RFC is hell. I wish its author the best of luck (he'll need it).

Only if the RFC pre-dates the technical solution, which may have been a large part of the early resistance to this RFC. PEAR_Exception is hardly mature. It's got great ideas, but is untested in rigorous situations and very new.

Yes it can be handled separately. Your example shows this perfectly. For all the mess you managed to stick in there, the example has no error handling whatsoever. Only warnings are in there. We need to define a way to handle those, naturally, but most concerns in warning handling are independent from error handling (except for upgrading/downgrading warnings/errors).

Right, upgrading/downgrading is a missing sentence in the existing RFC - something like "upgrading a warning to an error or downgrading an error into a warning is a crucial part of error handling and is not covered in this document as it has not been fully worked out. It will be added when the technical details are worked out."

The question of how to handle multiple errors is equally necessary to standardize. Leaving this up to the developer will only hurt the users. All of these questions need to be a part of the error handling guideline before it makes it into the coding standard.

This makes it the third time I pose you this request: Please provide a real world example where multiple errors *must* be used. The only

Another example: saxon parsing of xml. Any saxon parser simply continues to churn along, and you cannot redesign the thing to use exceptions for true errors such as a missing package name, or missing filelist in package.xml, unless you only wish to catch the very first error.

My problem with multiple errors is one of definition. In order to have a multiple error, I must, upon stumbling on the first error, continue execution on to the next one. However, if I could continue execution after the first error, then it really wasn't an error, was it? Errors are program conditions where it can't continue.

That's distorting the definition of an error. Parsing can continue, but the user expects a valid xml file, so any invalidity is an error. If there is more than one invalid portion of the file, that is more than one error. The definition of an error is too narrow if it doesn't include this condition. Greg