RE: [PHP-DEV] Allow exceptions in __toString()
| From: | Anatol Belski | Date: | Mon, 29 Jun 2015 07:49:01 +0000 |
| Subject: | RE: [PHP-DEV] Allow exceptions in __toString() | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-86935@lists.php.net to get a copy of this message | ||
Hi Nikita,
> -----Original Message-----
> From: Nikita Popov [mailto:nikita.ppv@gmail.com]
> Sent: Thursday, June 25, 2015 2:53 PM
> To: PHP internals; Dmitry Stogov
> Subject: [PHP-DEV] Allow exceptions in __toString()
>
> 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?
>
Given the expressed concerns, despite the change itself is a good thing when working properly, IMHO
we shouldn't urge it into 7.0. If having it now can lead to subtle improper behavior and even
worse bugs, preferable were to have a complete patch in 7.1.
Regards
Anatol