Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:87037 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 4129 invoked from network); 5 Jul 2015 23:03:07 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 Jul 2015 23:03:07 -0000 Authentication-Results: pb1.pair.com smtp.mail=bobwei9@hotmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=bobwei9@hotmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.98 as permitted sender) X-PHP-List-Original-Sender: bobwei9@hotmail.com X-Host-Fingerprint: 65.55.111.98 blu004-omc2s23.hotmail.com Received: from [65.55.111.98] ([65.55.111.98:53866] helo=BLU004-OMC2S23.hotmail.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 2A/46-21549-9A7B9955 for ; Sun, 05 Jul 2015 19:03:06 -0400 Received: from BLU436-SMTP121 ([65.55.111.72]) by BLU004-OMC2S23.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Sun, 5 Jul 2015 16:03:02 -0700 X-TMN: [DXJlfIeejZQbYsFUXH/oUQzY1cED7+ww] X-Originating-Email: [bobwei9@hotmail.com] Message-ID: Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) In-Reply-To: Date: Mon, 6 Jul 2015 01:02:56 +0200 CC: Stanislav Malyshev , =?utf-8?Q?Johannes_Schl=C3=BCter?= , PHP internals Content-Transfer-Encoding: quoted-printable References: <1435240516.15676.7.camel@kuechenschabe> <1436127623.5633.4.camel@kuechenschabe> <559994AB.3090102@gmail.com> To: Nikita Popov X-Mailer: Apple Mail (2.2098) X-OriginalArrivalTime: 05 Jul 2015 23:02:59.0085 (UTC) FILETIME=[BC88CBD0:01D0B776] Subject: Re: [PHP-DEV] Allow exceptions in __toString() From: bobwei9@hotmail.com (Bob Weinand) > Am 05.07.2015 um 23:45 schrieb Nikita Popov : > On Sun, Jul 5, 2015 at 10:51 PM, Nikita Popov = wrote: >> On Sun, Jul 5, 2015 at 10:33 PM, Stanislav Malyshev = >> wrote: >>=20 >>> Hi! >>>=20 >>>>>> 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: >>>>>=20 >>>>> I summarize this a bit freely as "We already have places which are = hard >>>>> to understand an predict, so let's add more!" >>>>>=20 >>>>=20 >>>> That, or "Let's not be hypocrites". >>>=20 >>> 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. >>=20 >>=20 >> 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). >>=20 >> 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. >>=20 >=20 > 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. >=20 > 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. >=20 > Nikita We have a rather messy behavior here=E2=80=A6 Failed object -> string is an error (if not caused by exception: = E_RECOVERABLE) Everything else a notice with return value 1? So, how are we handling code which likes to convert recoverables into = exceptions? That's not that rare. Sure=E2=80=A6 we're passing the empty string forward? and the code = calling zval_get_string() is continued=E2=80=A6 We already *have* that behavior. Can we please add consistency here and = always return an empty string to be passed forward? Or=E2=80=A6 as Nikita proposed always do a real fatal (E_ERROR). In case = we display E_ERROR, I'd like to ensure that the exception is displayed = properly in any case. I totally am on Nikitas side that either everything should be exception = or fatal. Recoverable isn't doing any good here. But I strongly feel for allowing exceptions here. P.s.: Ideally, we'd also change the object -> int/float cases to behave = consistently with the strings. But that's maybe now off-scope for 7.0=E2=80= =A6 Bob=