Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113095
MIME-Version: 1.0
References: <CAFPFaMJ-jrODtMsHZFEbJMZcbUYavDg6m0pJJQV-LXycsa6q5g@mail.gmail.com>
In-Reply-To: <CAFPFaMJ-jrODtMsHZFEbJMZcbUYavDg6m0pJJQV-LXycsa6q5g@mail.gmail.com>
Date: Fri, 5 Feb 2021 23:41:34 +0000
Message-ID: <CA+p1FaYiMZ-+5m74NkYdWjE61Gh8rkQX8=OG38j+8CteWF2w3g@mail.gmail.com>
To: "G. P. B." <george.banyard@gmail.com>
Cc: PHP internals <internals@lists.php.net>, Sara Golemon <pollita@php.net>, 
	Gabriel Caruso <carusogabriel@php.net>
Content-Type: multipart/alternative; boundary="000000000000ee088805ba9f5c09"
Subject: Re: [PHP-DEV] Interaction between finally blocks and exit()
From: davidgebler@gmail.com (David Gebler)

--000000000000ee088805ba9f5c09
Content-Type: text/plain; charset="UTF-8"

Interesting. I'm not sure there's a "correct" answer here, but FWIW on
balance my feeling is the expectation that exit() will immediately
terminate a script (registered shutdown functions and destructors aside)
should take precedence over the expectation that finally blocks will always
execute, just because if you've got an exit/die inside a try block, I think
it is reasonable to expect that you have already done anything that needs
to be done before you get there (i.e. that your intent is for nothing else
to happen), or to consider it a bug (certainly eyebrow raising code smell)
otherwise. It's not the kind of use case finally was conceptually intended
to address. And unlike an explicitly declared and self contained shutdown
function or destructor, this could lead to what is effectively shutdown
code being far removed and in a seemingly-random place in the code in
relation to where the exit call occurs, maybe in a different file and not
obvious to track down.

Dave


On Fri, Feb 5, 2021 at 1:10 PM G. P. B. <george.banyard@gmail.com> wrote:

> Greetings internals,
>
> While working on rewriting the PHP docs about errors and error handling [1]
> I came across a change of behaviour in an edge case of an edge case.
>
> finally blocks are meant to be always executed regardless that an Exception
> has been thrown or not, which it does, however a call to exit() (or die()
> as they are aliases).
> This can be seen with the following example: https://3v4l.org/6Tger
>
> However, there is one case where finally blocks are executed when exit() is
> used, namely when a generator has a finally block and exit() is called
> during its traversal, an example of this in action can be seen here:
> https://3v4l.org/HGKHS
>
> The behaviour of this edge case of an edge case is highly dependent on the
> version of PHP where this is run, PHP 5.5, 5.6, 7.0, early version of PHP
> 7.1, PHP 7.2.0, PHP 7.2.1, and PHP 8.0 all run the finally block on exit().
> Later versions of PHP 7.1, 7.2.2 and above and PHP 7.3 and 7.4 all skip the
> finally block.
>
> Frankly this is already going to be a mess to document, but this begs the
> question is there a "bug" in executing the finally blocks in generators
> during a call to exit() or is the "bug" to not execute finally blocks when
> exit() is called.
>
> I've CCed the PHP 8.0 RMs as if the consensus is that skipping finally
> blocks after a call to exit() is performed it would be wise to change this
> behaviour in PHP 8.0 only and land this ASAP, even though it's a BC break.
>
> Interested in hearing your thoughts.
>
> Best regards,
>
> George P. Banyard
>
> [1] https://github.com/php/doc-en/pull/320
>

--000000000000ee088805ba9f5c09--