On Thu, Aug 4, 2016 at 11:10 AM, Bishop Bettini <bis...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
