Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94503
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <a84c670e-3dab-0d38-71d5-778079bb9807@gmail.com>
References: <2c547cd2-408d-238b-2b5c-e6f7f24f0e7a@fleshgrinder.com> <a84c670e-3dab-0d38-71d5-778079bb9807@gmail.com>
Date: Wed, 13 Jul 2016 22:29:05 +0200
Message-ID: <CAF+90c9u8kDUJvcm=X4h4g8Ts9Go1cOdK80U_pvKmMPcZWBmWA@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c05b1d09f387205378a3cf1
Subject: Re: [PHP-DEV] [RFC DISCUSSION] Error Storage Behavior
From: nikita.ppv@gmail.com (Nikita Popov)

--94eb2c05b1d09f387205378a3cf1
Content-Type: text/plain; charset=UTF-8

On Mon, Jun 27, 2016 at 9:53 PM, Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> Hi!
>
> > Currently error_get_last() always contains the last error that occurred,
> > however, this is actually not desired if the last error was an exception
> > that was caught.
> >
> > https://github.com/php/php-src/pull/1936
>
> I think conditioning warnings on whether exception is caught or not is a
> very bad idea. However, having _either_ exception _or_ PHP error and not
> producing both (except in the case where uncaught exception becomes
> fatal error I guess) may be a good idea, but it needs careful checking
> of the implications. In general, old error mechanism and exceptions are
> not very good combination, and using them together may be troublesome.
>
> It's definitely not "just a bug fix" - it needs careful check of what
> exactly happens when.
>

I think there is some confusion about this change because the description
was unclear.

The change is **only** about EH_THROW handling. EH_THROW is used by
extensions to replace warnings etc with exceptions. Currently the exception
is thrown, but error_get_last() still behaves as if the warning was thrown
instead. Fixing this does seem like a normal bug fix to me. Note that this
does not touch exceptions thrown from error handlers or similar in any way.

Basically the problem is that an extension using zend_throw_exception
directly and an exception throwing through EH_THROW will behave
differently, while there should be no difference.

The part about behavior being dependent on whether you catch the exception
or not: This is true only insofar as an uncaught exception generates a
fatal error and that fatal error is retrievable through error_get_last().
There is no special casing occurring here.

Nikita

--94eb2c05b1d09f387205378a3cf1--