Re: [RFC] Exceptions in the engine

On Tue, Oct 7, 2014 at 7:58 AM, Rowan Collins <rowan.collins@gmail.com> wrote: > 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). I would contend that catching a NullPointerException is not any more recoverable than most other EngineExceptions. I would also argue that you should never, in any language, catch a NPE. The only time you should catch an NPE is if you are catching all exceptions, such as in a FastCGI daemon that will cleanly shutdown afterwards.