Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77821
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.182 as permitted sender)
Message-ID: <54347443.60207@gmail.com>
Date: Wed, 08 Oct 2014 00:16:19 +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 <internals@lists.php.net>
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>	<DE822B1A-D07D-408C-96AF-644130629175@gmail.com> <CAFMT4NrsVfeJPg-BZ_QiHJRe-HiQD+SB_TPN=LSVTU6vj+vyig@mail.gmail.com>
In-Reply-To: <CAFMT4NrsVfeJPg-BZ_QiHJRe-HiQD+SB_TPN=LSVTU6vj+vyig@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------010604070707030000030107"
Subject: Re: [PHP-DEV] [RFC] Exceptions in the engine
From: rowan.collins@gmail.com (Rowan Collins)

--------------010604070707030000030107
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 07/10/2014 21:07, Levi Morrison wrote:
>>> 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.
> This is not a new idea; a very quick search turned up the CERT Oracle
> Coding Standard for Java:
>
> "Programs must not catch java.lang.NullPointerException. A
> NullPointerException exception thrown at runtime indicates the
> existence of an underlying null pointer dereference that must be fixed
> in the application code[...] Handling the underlying null pointer
> dereference by catching the NullPointerException rather than fixing
> the underlying problem is inappropriate for several reasons."
>
> I'll let you read the standard for the justification.

Assuming you mean this (you forgot the link, so I searched the quote): 
https://www.securecoding.cert.org/confluence/display/java/ERR08-J.+Do+not+catch+NullPointerException+or+any+of+its+ancestors

They give 3 reasons:

1) Performance overhead.
I have no idea whether this is true for PHP's implementation of 
Exceptions, or for the scenario which I came up with earlier.

2) Inability to know which part of the try{} block initiated the error.
This is a fair point, although why it is more true of these exceptions 
than any other, I'm not sure.

3) "programs rarely remain in an expected and usable state after a 
|NullPointerException| has been thrown"
As mentioned earlier, PHP is not Java, and the closest to a "Null 
Pointer" is actually "variable which you thought was going to be an 
object but turned out to be a scalar or array". The situations that lead 
to the exception are vastly different, so the chances of recoverability 
aren't really generalisable from one to the other.

To clarify, this is the kind of code I was thinking of:

$result = DataSource::newInstance()
    ->select('foo')
    ->from('bar')
    ->with('baz') // WHAT IF THIS RETURNS FALSE?
    ->using('id')
    ->where('foo_name', $name)
    ->and('active', true)
    ->fetchArray();

There are two ways I know of for dealing with an error midway through a 
chain like that:
1) Return a "Null Object", or an object which has been put into an error 
state, so that all following calls are executed, but do nothing.
2) Throw an exception, so that the chain finishes early, and the calling 
code knows an error has occurred.

If the library author has done neither of these, you will be faced with 
a "call to a member-function on a non-object" error. Your only recourse 
if you cannot / are unwilling to fix the library is to remove the 
elegance of the fluent interface and check an intermediate variable with 
is_object() or instanceOf on every line.

If that was an exception, then you, as the library consumer, could catch 
it, just like you would catch a custom exception thrown by a more 
conscientious library author.

> The point is that a few applications (and I mean a*very*  few) need to
> be able to handle these kinds of failures; for example a web server
> shouldn't crash because the application throws a NullPointerException;
> rather the worker dies and the client will be sent a 500 error and the
> web server continues to run normally.

Just to clarify, are you broadly in favour of Engine Exceptions, or 
against the whole idea? Because this sounds like a call for something 
completely separated from the userland notion of "Exception", and indeed 
something that would rarely even be written in PHP rather than C in an 
extension.

Regards,

-- 
Rowan Collins
[IMSoP]


--------------010604070707030000030107--