Re: [RFC] Exceptions in the engine

On 24/10/2013 19:01, Adam Harvey wrote:

On 24 October 2013 10:41, Nikita Popov <nikita.ppv@gmail.com> wrote:

I'd like to propose an RFC, which allows the use of exceptions within the engine and also allows changing existing fatal errors to exceptions

I love the idea — unified error and exception handling would be a huge win both for simplifying code bases and teaching new developers — but I don't see any possible way we could do this in a 5.x release. The BC issues are just too great, and too many people rely heavily on the set_error_handler() behaviour that we have today.

FWIW, as an outsider, I'd tend to agree with this. It might be possible to implement this in a backwards compatible way, but there would be a lot of details to consider. More importantly, if this isn't a big enough change to warrant a major release, what is? The more major features make it into 5.x, with BC carefully maintained, the more it feels like 5.x will go on living indefinitely, with the implication - according to the current release process - that deprecated or broken APIs will "never" be removed or fixed.

I wouldn't selectively convert errors to exceptions as the "policy changes" section suggests — let's do them all and be done with it

This I agree with even more strongly, but I also don't think this should be a one-to-one mapping of the existing errors. From what I can see, the current patch uses neither sub-classes nor exception codes, just the existing message strings. This seems like a massive missed opportunity - a big part of exception handling is choosing which exceptions to handle, and at the moment, the only way to detect what error was thrown is by string matching, including accounting for substituted parts. It would also be nice to consider changing the handling of non-fatals as well, although I'm not quite sure how they should work. Again, there is currently no way to detect the "type" of a warning or notice, only its severity; nor is there an easy way to have different handlers for different severities. Those severities can also be pretty arbitrary: e.g. an undefined constant issues an E_NOTICE, but a class constant is E_ERROR, presumably for historical reasons, which would matter less if there were additional meta-data to recognise them by. The other rather more blue-sky thought I had is that it would be nice to scope error-handling "lexically", in the sense of all functions in a particular included library being under a different error-handling regime from the outer program, reagardless of execution order. There are old modules in PEAR which work fine with current versions of PHP, but emit lots of E_DEPRECATED or E_NOTICE messages; what I really want to say is "yes, our use of that whole module is deprecated, we're not going to clean it up, but our own code should be nice and clean". Regards, -- Rowan Collins [IMSoP]