On Thu, Aug 4, 2016 at 12:11 PM Bishop Bettini <bis...@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
