Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94834
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain mudsite.com designates 209.85.220.175 as permitted sender)
MIME-Version: 1.0
References: <CAEYWF=6wG+HwxsRbzNeeWpdhJWJxd=0fMtdByYAkrz4MBp2OBA@mail.gmail.com>
In-Reply-To: <CAEYWF=6wG+HwxsRbzNeeWpdhJWJxd=0fMtdByYAkrz4MBp2OBA@mail.gmail.com>
Date: Thu, 04 Aug 2016 19:07:06 +0000
Message-ID: <CADVQu1Sttp6URjDgFJsxWK_WOA3hVBNMMc6JH8zZ49yBKy6+kQ@mail.gmail.com>
To: bishop@php.net, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a114d6a48930548053943a849
Subject: Re: [PHP-DEV] Tracing exit()
From: dave+php@mudsite.com (David Walker)

--001a114d6a48930548053943a849
Content-Type: text/plain; charset=UTF-8

On Thu, Aug 4, 2016 at 12:11 PM Bishop Bettini <bishop@php.net> wrote:

> Hi!
>
> exit (and its doppelganger die) is a hard stop to the engine and there is
> little telemetry provided about the circumstances (file, line, message, and
> code). In source I control, exit is no big deal: I don't use exit! But in
> library code, exit can be frustrating.
>
> register_shutdown_function + debug_backtrace doesn't help, because the
> trace doesn't flow out of the shutdown function. xdebug helps to find the
> exit frame, but cannot pinpoint the exact line. It seems like the engine
> could help with a little extra telemetry.
>
> 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();
> ?>
>
> Or, alternatively, I wonder if a method to convert an exit to an exception
> would be better:
>
> <?php
> echo ini_get('zend.exit_exception'); // "1"
>
> try {
>     require 'vendor/autoload.php';
>     \Vendor\Package\Class::callsExit();
> } catch (\ExitException $ex) { // extends \RuntimeException
>     echo 'Stop that!';
> }
> ?>
>
> (In all these examples, "callsExit" is vendor code that performs an
> undesirable exit();)
>
> This latter approach feels more modern, at least from a user perspective,
> but it has the side effect of making exit recoverable. IMO, that's a good
> thing, because the conditions under which libraries exit may merely be
> exceptional for consuming applications.
>
> 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.
>
> 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?
>
> bishop
>

I'd be supportive of this, as you define it.

However, since you're asking for comments, I'd really be supportive of some
means in which telemetry of a call could be gathered for more than just
exit & die.  Rarely, but not never, we have a new-ish developer who's just
been given perms to commit/update production and accidentally pushes code
with print-to-screen debugging.  It would be amazing if this concept could
be extended out to general userland functions/functions/constructs.  To be
able to see what lines a specific call is being made to help track down
where offending code might be happening.

-- Dave

--001a114d6a48930548053943a849--