Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87056
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.215.10 cause and error)
Message-ID: <1436203060.23453.88.camel@kuechenschabe>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Stanislav Malyshev <smalyshev@gmail.com>, PHP internals
	 <internals@lists.php.net>
Date: Mon, 06 Jul 2015 19:17:40 +0200
In-Reply-To: <CAF+90c_PGRPNOJ4KanZ5D8bnBHxWs8kzyeeA-Xgv4D7CV=4Y1Q@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>
	 <CAF+90c_PGRPNOJ4KanZ5D8bnBHxWs8kzyeeA-Xgv4D7CV=4Y1Q@mail.gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-G06lSW2fxmBngKrvQLfW"
Mime-Version: 1.0
Subject: Re: [PHP-DEV] Allow exceptions in __toString()
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

--=-G06lSW2fxmBngKrvQLfW
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, 2015-07-05 at 23:45 +0200, Nikita Popov wrote:
> 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!
>                =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:
>                 >>
>                 >> 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".
>                =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
>        =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
>=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.

I fully agree that the current situation is bad. I just don't see an
improvement by this change, rather a new set of WTFs for the user.

In the ideal world we can throw everywhere without issues (well, except
maybe exceptions escaping from destructors in shutdown maybe ... while
maybe that's not different from other uncaught exceptions) Maybe we have
to restructure internal exception handling for that? Maybe we can create
a plan leading there for a future version?

johannes
  (who dreams of a complete new and unified error&exception handling,
  but never managed to sit down to create a good proposal ...)


--=-G06lSW2fxmBngKrvQLfW
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAABAgAGBQJVmrg0AAoJEH3sTmn8nIPXQBIH/2nb1FgmBpy3gs9yGtshgo6V
vMz0EPsScRKlwKLRgd+hoQd5cc8D/q07XPe3e2WUt8zHcmsDkjRiLNzFA+3NdgfB
retIF+1JrxI6Qe5VJ3zDrQvU1MGMQzbC6YDbK098IFl9/DSYNwBwf1djj3n/rUKX
I9duWWH3uZ+OWLwVhJNdGdJvBJCkGZb+zK4gFm0MQpS1efchgMeFfxFV5cpRxEaa
5Vb8T9YjaSFzuUblAuDKP2+e0eKe1neEzfvhdpfpYqjefexwA9mXo6h9TDs2HSYo
CveVQUP7OAbnWvL7jkoqAaY0jSQy64FJanqatAENk3FCUr+T7766pZ5QMXMk9kE=
=eyft
-----END PGP SIGNATURE-----

--=-G06lSW2fxmBngKrvQLfW--