Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107515
Message-ID: <36C65A63-3D5D-4EA4-A088-5E6B107F779E@trowski.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_5F098A3B-832A-45D4-A7A7-761B0353F8DF"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 11 Oct 2019 11:26:57 -0500
In-Reply-To: <CAF+90c93ic6E40imvE5GS10tO-ZDtRcE+dnDW9ey+S+ZmQqkSg@mail.gmail.com>
Cc: Marcio Almada <marcio.web2@gmail.com>,
 PHP internals <internals@lists.php.net>
To: Nikita Popov <nikita.ppv@gmail.com>
References: <CAF+90c9EQ+UGe-y+V_n1QrYkXtPh1uWKXXWEJQUe0xP-MjV7_w@mail.gmail.com>
 <CAOsHV+tpnh9RvbBqXNjs2yp0muu_GHRf3CXVSxg9v081EDGRWQ@mail.gmail.com>
 <CAF+90c_iPDv4RCCG-1vd=cVo-j8GO-BBf=m2KqBQm24xVFwNmg@mail.gmail.com>
 <2406F2E7-CD65-4E30-A98C-C09FB52B4F2B@trowski.com>
 <CAOsHV+tcNe9ZNzjir7k9G-MmEvZEUcva_f25=f6H68GcC+ZwAg@mail.gmail.com>
 <CAF+90c93ic6E40imvE5GS10tO-ZDtRcE+dnDW9ey+S+ZmQqkSg@mail.gmail.com>
Subject: Re: [PHP-DEV] exit() via exception
From: aaron@trowski.com (Aaron Piotrowski)

--Apple-Mail=_5F098A3B-832A-45D4-A7A7-761B0353F8DF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Oct 11, 2019, at 10:21 AM, Nikita Popov <nikita.ppv@gmail.com =
<mailto:nikita.ppv@gmail.com>> wrote:
>=20
>> Hi!
>>=20
>> So maybe it narrows down to:
>>=20
>> Is there an essencial attempt to improve `exit()` handling from the
>> userland perspective or should the focus be solely on solving the
>> memory management issue pointed out in the beginning of the thread?
>>=20
>> If the scope is to also improve userland, option 3 could be the way =
to
>> go indeed but I confess to do not be a fan of another callback
>> registering thing... it feels hard to predict when you consider:
>>=20
>> ```
>> catch_exit(function(){
>>    exit(); // what happens here? We still have to guarantee `exit` to
>> halt at some point.
>> });
>> ```
>>=20
>> And what are the interactions with `register_shutdown_function`? I
>> suppose the `catch_exit` stack has to be run before the
>> `register_shutdown_function` stack? Considering the behavior in the
>> docs.
>>=20
>=20
> I think I was a bit unclear in how the catch_exit() function is =
intended to
> work: It's not an atexit handler, it's basically a try/catch block for
> exits.
>=20
> $exitExceptionOrNull =3D catch_exit(function() {
>    // Run code that may contain exit() here
> });
>=20
> or possibly even more explicitly as:
>=20
> catch_exit(function() {
>    // Run code that may contain exit() here
> }, function($exitCode, $exitMessage) {
>    // This is called if an exit() occurred
> });

The second option seems better, as it's a lot more obvious what code =
will be executed if exit() is called and what will not be.

Would a set_exit_handler function be possible, similar to =
set_exception_handler?

>=20
> I like option 4 much more for now. It allows tackling the root issue
>> and still leaves possibilities open regarding how the exception
>> hierarchy could be and how the handling of `exit` could happen
>> (through a catch at userspace or callback registering).
>>=20
>=20
> I guess we should do that as the first step in any case ... everything =
else
> would be extensions on top of that, but this would be the main =
technical
> groundwork.
>=20
> Nikita

Option 4 of course would be fine for now. Once that's done, we can =
decide how exits could be "caught" in the future.


> On Fri, Oct 11, 2019 at 5:13 PM Marcio Almada <marcio.web2@gmail.com =
<mailto:marcio.web2@gmail.com>> wrote:
>=20
>>>=20
>>> EngineShutdown could be a special exception to the engine, being =
handled
>> like an exception internally, but not implement Throwable and =
therefore not
>> an exception from user-land's point-of-view.
>>>=20
>>> EngineShutdown could be added to the list of "throwables", but =
forbid
>> instigation in user-land.
>>>=20
>> =
https://github.com/php/php-src/blob/db233501ff9d56765ef4a870b777a643c21367=
11/Zend/zend_exceptions.c#L909-L916 =
<https://github.com/php/php-src/blob/db233501ff9d56765ef4a870b777a643c2136=
711/Zend/zend_exceptions.c#L909-L916>
>>>=20
>>> No catch block would catch it, because it wouldn't implement =
Throwable
>> nor extend Exception or Error.
>>>=20
>>=20
>> Very elegant solution!
>>=20
>> PS: Naming things is hard, but `Throwable` could not have been a
>> better choice in retrospect. Ty ;)

Thanks! Every once-in-a-while I manage to name something correctly!

>>=20
>>> Aaron Piotrowski
>>>=20
>>=20
>> M=C3=A1rcio

Aaron Piotrowski=

--Apple-Mail=_5F098A3B-832A-45D4-A7A7-761B0353F8DF--