Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77819
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.180 as permitted sender)
User-Agent: K-9 Mail for Android
In-Reply-To: <CAFMT4NrHJ8i-qntG3dS9H3o96ZJ_PagT4KiwYSz5JvcXUq5=pg@mail.gmail.com>
References: <CAF+90c-7w1fLqmffYvPRhmtt8rzESEpSmW8vfMD-YfLt1mG_8w@mail.gmail.com> <9CFCFC24-A670-4DBC-8042-C073B62958A2@strojny.net> <5433F174.8060204@gmail.com> <CAFMT4NrHJ8i-qntG3dS9H3o96ZJ_PagT4KiwYSz5JvcXUq5=pg@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8
Date: Tue, 07 Oct 2014 20:46:29 +0100
To: internals <internals@lists.php.net>
Message-ID: <DE822B1A-D07D-408C-96AF-644130629175@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Exceptions in the engine
From: rowan.collins@gmail.com (Rowan Collins)

On 7 October 2014 18:52:35 GMT+01:00, Levi Morrison <levim@php.net> wrote:
>On Tue, Oct 7, 2014 at 7:58 AM, Rowan Collins <rowan.collins@gmail.com>
>wrote:
>> 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. 

In the scenario I just listed, the catch is effectively emulating an isset()/is_object() check before each chained operation. Seems perfectly reasonable to me. (If I'm not much mistaken, CoffeeScript has an operator for this precise case.)

> 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.

If you're not allowed to catch it, why make it an exception? Benefits such as unwinding finally blocks and destructors, and collecting backtraces, are secondary effects, not really fundamental to exceptions.

Perhaps "NullPointerException" is not a good name, as it has rather different implications than in other languages. In PHP, using the -> operator on a non-object isn't much different from calling a function with incorrect types. It shouldn't happen if your code is properly unit-tested, but it doesn't necessarily mean a catastrophic failure has occurred.

Regards,
-- 
Rowan Collins
[IMSoP]