Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77820
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.51 as permitted sender)
MIME-Version: 1.0
Sender: morrison.levi@gmail.com
In-Reply-To: <DE822B1A-D07D-408C-96AF-644130629175@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>
	<DE822B1A-D07D-408C-96AF-644130629175@gmail.com>
Date: Tue, 7 Oct 2014 14:07:08 -0600
Message-ID: <CAFMT4NrsVfeJPg-BZ_QiHJRe-HiQD+SB_TPN=LSVTU6vj+vyig@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)

>> 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.

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.