Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86862
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.48 as permitted sender)
MIME-Version: 1.0
Date: Thu, 25 Jun 2015 14:52:42 +0200
Message-ID: <CAF+90c9jJVVOwXGrCYo4yWx=LtfqycccNNS3e8AvAO7PhLkiyA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>, Dmitry Stogov <dmitry@zend.com>
Content-Type: multipart/alternative; boundary=047d7bacc2c066b05705195719a1
Subject: Allow exceptions in __toString()
From: nikita.ppv@gmail.com (Nikita Popov)

--047d7bacc2c066b05705195719a1
Content-Type: text/plain; charset=UTF-8

Hi internals!

Currently it's not possible to throw an exception from __toString() -
instead you will get a (real) fatal error. This is becoming more and more
problematic as time goes on, e.g. with PHP 7 an exception can be triggered
as a result of a VM error or even a parse error.

I'd like to lift this restriction. A patch can be found here:
https://github.com/php/php-src/pull/1364

Apart from allowing exceptions, the patch also converts two leftover
recoverable fatal errors relating to __toString() into Error exceptions.

Furthermore the patch makes sure that we correctly (i.e. without leaks and
without superfluous notices or other side-effects) handle __toString()
exceptions in the engine. This includes concatenation and interpolation,
but also things like writing $foo->$object or ${$object}.
zend_parse_parameters() and Fast ZPP also deal with exceptions correctly.

However what it doesn't do, and what I wouldn't consider feasible to do, is
ensure that every single string conversion in library functions is
exception safe. Personally I don't think this is a blocking issue, as the
worst that can happen is usually an additional superfluous warning to be
thrown, or something similar. If cases like this turn up, we can
specifically target them.

It should also be noted that whatever issues with exceptions-safety may
remain, they already exist now (plus those the patch fixes), because the
two aforementioned recoverable fatal errors can be converted to exceptions
(and anyone doing blanket ErrorException conversions will do this).

So basically the question here is, is this partial solution acceptable for
us?

Thanks,
Nikita

--047d7bacc2c066b05705195719a1--