Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69856
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <52697BAF.7020709@sugarcrm.com>
References: <CAF+90c8OgW4Nonaz+HQn+gi4r+AdaEMXsTxCAhn=WO-+aQQsZQ@mail.gmail.com>
	<52697BAF.7020709@sugarcrm.com>
Date: Thu, 24 Oct 2013 22:16:27 +0200
Message-ID: <CAF+90c_rVRdk9jo08q5-=gOBXqLRR-uZbzfN6P3bQe--H9NRkA@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b5d5c14088a6e04e9824f40
Subject: Re: [PHP-DEV] [RFC] Exceptions in the engine
From: nikita.ppv@gmail.com (Nikita Popov)

--047d7b5d5c14088a6e04e9824f40
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Oct 24, 2013 at 9:57 PM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> Hi!
>
> Looking at the patch, it converts zend_error_noreturn into
> ZEND_IMPOSSIBLE, which is nothing in non-debug mode. This means code
> that expected that execution ceases it this point (and jumps to a safe
> bail-out point) now just continues in non-debug mode (probably causing
> crash or memory corruption) or exits the process on failed assert in
> debug mode. I'm not sure it is a good idea to do this.


To make sure that there are no misunderstandings, Stas is referring to two
particular occurrences where E_ERROR has been replaced with a
ZEND_IMPOSSIBLE macro. Both occurrences are unreachable code (or so I
judged), so they are effectively assertions implemented using E_ERROR
rather than assert(). The ZEND_IMPOSSIBLE macro is a more explicit way of
saying assert(0). PHP removes assertions in non-debug builds
(optimization), so this follows suit.

I did not mention this in the RFC because I'm not yet sure this change is
necessary and I might yet keep them as (pointless) fatal errors instead,
just in case. This is mainly a note to myself that I looked at the error
and decided that it does not require conversion.


> A lot of code assumes execution does not proceed past E_ERROR, but

exceptions do not work that way.
>

That's correct. In the places where I replaced fatal errors with exceptions
I make sure to free resources and handle the exception.

Nikita

--047d7b5d5c14088a6e04e9824f40--