Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94843
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.214.52 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <CAEYWF=6wG+HwxsRbzNeeWpdhJWJxd=0fMtdByYAkrz4MBp2OBA@mail.gmail.com>
References: <CAEYWF=6wG+HwxsRbzNeeWpdhJWJxd=0fMtdByYAkrz4MBp2OBA@mail.gmail.com>
Date: Thu, 4 Aug 2016 16:37:57 -0700
Message-ID: <CAESVnVp21uMDwewTb7MSQwRWYj9xm50XajH=ByL2jvToBjSSZA@mail.gmail.com>
To: Bishop Bettini <bishop@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Tracing exit()
From: pollita@php.net (Sara Golemon)

On Thu, Aug 4, 2016 at 11:10 AM, Bishop Bettini <bishop@php.net> wrote:
> I'm wondering if the shutdown functions could access telemetry:
>
> <?php
> register_shutdown_function(function () {
>
>     $context = shutdown_get_context();
>
>     /** array ( 'exit' => array ('file' => '/path/to/Foo.php', 'line' =>
> 242, 'message' => "Calling exit() because...", 'code' => 0)) */
>     // different SAPI may expand on this context
> });
>
> require 'vendor/autoload.php';
> \Vendor\Package\Class::callsExit();
> ?>
>
I like this idea!  I can easily imagine the frustration of having
untrackable calls to exit, and the effort to expose this info for
logging is pretty trivial to implement.

> Or, alternatively, I wonder if a method to convert an exit to an exception
> would be better:
>
Eh... That feels less-obvious to me for the reasons you stated in your
OP.  I'm not convinced that being able to recover from an
\ExitException is a good thing, but I don't have a compelling reason
why it's bad, so I'll keep thinking about that.

> However, I'm uncertain of an "exit exception" implementation. Perhaps when
> INI enabled, zend_compile_exit could rewrite to emit ZEND_THROW with a
> synthetic node. Or all the ZEND_EXIT could be updated to throw instead of
> bailout. Don't know.
>
I'd probably leave the compile step alone and have the opcode handler
switch on the INI setting.  One lil' integer compare on an instruction
meant to *stop* execution isn't going to be a problem. (You wouldn't
have exit being called repeatedly in a loop)

> TL;DR: Engine support for tracing/trapping/debugging exit helps developers
> find and avoid hard exits in dependent code they don't control. Thoughts on
> proceeding with an RFC?
>
+1 from me.

-Sara