Lars Strojny wrote (on 06/10/2014):
Hi Nikita,
On 06 Oct 2014, at 23:53, Nikita Popov <nikita....@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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
