Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77814
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.174 as permitted sender)
MIME-Version: 1.0
Sender: morrison.levi@gmail.com
In-Reply-To: <5433F174.8060204@gmail.com>
References: <CAF+90c-7w1fLqmffYvPRhmtt8rzESEpSmW8vfMD-YfLt1mG_8w@mail.gmail.com>
	<9CFCFC24-A670-4DBC-8042-C073B62958A2@strojny.net>
	<5433F174.8060204@gmail.com>
Date: Tue, 7 Oct 2014 11:52:35 -0600
Message-ID: <CAFMT4NrHJ8i-qntG3dS9H3o96ZJ_PagT4KiwYSz5JvcXUq5=pg@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] Exceptions in the engine
From: levim@php.net (Levi Morrison)

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.