Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77800
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.173 as permitted sender)
Message-ID: <5433F174.8060204@gmail.com>
Date: Tue, 07 Oct 2014 14:58:12 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAF+90c-7w1fLqmffYvPRhmtt8rzESEpSmW8vfMD-YfLt1mG_8w@mail.gmail.com> <9CFCFC24-A670-4DBC-8042-C073B62958A2@strojny.net>
In-Reply-To: <9CFCFC24-A670-4DBC-8042-C073B62958A2@strojny.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Exceptions in the engine
From: rowan.collins@gmail.com (Rowan Collins)

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]