Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87036
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.50 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAF+90c85xzxJMrjEFUSm0c0kntxi-kG40NXnrK=e9K_sC_a+aA@mail.gmail.com>
References: <CAF+90c9jJVVOwXGrCYo4yWx=LtfqycccNNS3e8AvAO7PhLkiyA@mail.gmail.com>
	<1435240516.15676.7.camel@kuechenschabe>
	<CAF+90c9beR6aFaTHiPKXA-sjydOcLSeu8+8_7N9z4MaMaVYkjw@mail.gmail.com>
	<1436127623.5633.4.camel@kuechenschabe>
	<CAF+90c9iiaqWdZs1aDXkfgUDJQQVhpnMF9f2XeN6OGRhHqsSmA@mail.gmail.com>
	<559994AB.3090102@gmail.com>
	<CAF+90c85xzxJMrjEFUSm0c0kntxi-kG40NXnrK=e9K_sC_a+aA@mail.gmail.com>
Date: Sun, 5 Jul 2015 23:45:14 +0200
Message-ID: <CAF+90c_PGRPNOJ4KanZ5D8bnBHxWs8kzyeeA-Xgv4D7CV=4Y1Q@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: =?UTF-8?Q?Johannes_Schl=C3=BCter?= <johannes@schlueters.de>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7bf0bfc2461d4a051a27b490
Subject: Re: [PHP-DEV] Allow exceptions in __toString()
From: nikita.ppv@gmail.com (Nikita Popov)

--047d7bf0bfc2461d4a051a27b490
Content-Type: text/plain; charset=UTF-8

On Sun, Jul 5, 2015 at 10:51 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:

> On Sun, Jul 5, 2015 at 10:33 PM, Stanislav Malyshev <smalyshev@gmail.com>
> wrote:
>
>> Hi!
>>
>> >>> I can see your concern here -- however this is nothing specific to
>> >>> exceptions thrown from __toString(). There is are a number of ways you
>> >>> can end up in this situation, the two most common being:
>> >>
>> >> I summarize this a bit freely as "We already have places which are hard
>> >> to understand an predict, so let's add more!"
>> >>
>> >
>> > That, or "Let's not be hypocrites".
>>
>> I don't think the position of "let's not add more unpredictable behavior
>> to the engine" is adequately described as "hypocrite". We know there are
>> interruption problems and such in the engine, we know some of them are
>> hard to fix. However, adding a different class of those doesn't make it
>> better in any way. If we find a solution that allows us to not introduce
>> new unpredictable behaviors - I'm all for it, it's great. Maybe the code
>> that allows to throw exceptions the same way we do with errors, maybe
>> some way to not get unpredictable results on conversions. But we can't
>> just ignore it because there are other problems in the engine too.
>
>
> Sorry, I just find it somewhat weird that we consider some of the
> exceptions generated as the result of __toString calls to be okay (error
> handler exceptions), while others are considered to be too dangerous to
> allow (direct exceptions).
>
> But maybe I just approached this from the wrong direction. Instead of
> allowing exceptions in __toString in combination with some hardening of the
> VM, maybe we should just convert the recoverable fatal errors __toString
> currently throws to actual fatal errors? Not a huge fan of doing that, but
> at least it's consistent.
>

I just realized that this wouldn't quite cut it, because our object to
integer and object to float conversions currently throw notices, which can
be converted to exceptions and to-int conversions at least are all over the
place. Presumably it's not acceptable to change these notices to fatal
errors.

Furthermore the array-to-string conversion also throws a notice since 5.4,
which can also result in an exception. While we approved an RFC (not
implemented) to make this a recoverable error, I suspect making this a real
fatal error will not be met with much enthusiasm.

Nikita

--047d7bf0bfc2461d4a051a27b490--