Re: [RFC] Exceptions in the engine

Lars Strojny wrote (on 06/10/2014):

Hi Nikita, On 06 Oct 2014, at 23:53, Nikita Popov <nikita.ppv@gmail.com> wrote: [...]

As such I'm re-proposing this RFC for inclusion in PHP 7:

    https://wiki.php.net/rfc/engine_exceptions_for_php7

The RFC text is essentially the same as previously, with the primary difference being that parse errors are now converted to exceptions as well. This was previously not possible due to limitations in the compiler design.

I very much like the idea of making fatal errors exceptions, so: thumbs up! Is there a way to introduce different exception classes for different errors. E.g. - UndefinedMethodException for stdClass::method() - NullPointerException for null::method() - UndefinedFunctionException for invalid_function() - etc. They could all extend EngineException to have a common base class but I am sure we could find good abstractions for an exception inheritance tree. What do you think?

It was suggested in the previous discussion that this could be added later, but IMHO, it's a must. Part of the power of exceptions is that you can *selectively* catch them *when you know you can deal with the result*. Emitting a single EngineException will just encourage a kind of "pokemon exception handling", because the only way to use it is in a generic "something went wrong" handler. The semantics of that handler might be a bit tidier than one for E_RECOVERABLE_ERROR, but there's not a lot of extra power available. As an example where a specific exception would be useful, but a generic one would not, consider a fluent interface which sometimes bugs out and returns NULL. If wrapped in a NullPointerException these expected error conditions could be caught at runtime, while any other errors would continue to have their normal behaviour (such as triggering a higher-scoped catch-all/default exception handler). Regards, -- Rowan Collins [IMSoP]