Re: Tracing exit()

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