Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113233 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 99103 invoked from network); 23 Feb 2021 17:25:00 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 23 Feb 2021 17:25:00 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 024D51804B3 for ; Tue, 23 Feb 2021 09:13:32 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com [209.85.167.46]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 23 Feb 2021 09:13:31 -0800 (PST) Received: by mail-lf1-f46.google.com with SMTP id e7so12442271lft.2 for ; Tue, 23 Feb 2021 09:13:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pAinF7YO6I6VGQgYCeW975S6NBmeDVaQ0C2Zr/muJT4=; b=k+uc0UYSFmQqVcWkZ0hljX0AbV3F5TqNQfdwROcNV0QI02uYUB4xErMlieZSwcq89D u2uH7IE8yOSc0vgeNS07VqN340TIKowYi4tggiRZLieLRwZzq9RmbUDhin8voRgCjFOg L4Zd+S26kOURId8sTasghN80ODZu0p5xk35uwE+/wMz9568R6B5Q7GGeN26++HucMGzm WOQYTxwO6XzxhQJusRFyV/Z48LIkmoEgsCO/XuN5XkdpFyDjIj6iN/ToUYCgqIr50DjW /e1YBsFWSpo/xyTAct6QzcWB9+V1IUxrKNTCg244gL9Zbr/geFIJ+2QlKzbnq/F3UrTT wttg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pAinF7YO6I6VGQgYCeW975S6NBmeDVaQ0C2Zr/muJT4=; b=P2S5MfaPNQkQ3gWnVLe3Q5PstYm3IrdPPrTl21qtpVStJYbzib2E8CCj2Xwes/oDpr wwtTbjLCRLDWQ6SP87KAHP+0E6ly/1htUmco0rONw6U6zu7q2VOxuAlngqSmyHJN4lEM lKfX18ykbbhMoX1n6N0jImuq6U/5twdgzVAENDRNwna5X0pAPXP+dNgAKBUQwrhcSmQD Njj9l50hrcv6CkGseYq4eiWU1H0slvWvhIN2cZdlInF/7FibLP+c/AzsW8aNxWONhSns pcVe1nErQS32SzIoZqItUOqfNKnYY4DZxYUn4NCxNqRG2HBN5ZhyGjWnHVXiebRHEeyU cMiQ== X-Gm-Message-State: AOAM533YWYCnnMCiB6IgsE/bpz/g3a/Ay5ByeTQmer+RYVVS2YE7bTUB rFMp/P6QY2DIWIHkJjMRkg5YFhGSLlABOOpIMg== X-Google-Smtp-Source: ABdhPJx85v+2fcGzm2NOGmMvQQSUshJ1DqtITQzrMi+cmO1ftHVL1khgxIF2vY2Bpn4DXDPQqpLkmnxa8tsjWT9qPrw= X-Received: by 2002:ac2:55b1:: with SMTP id y17mr8494356lfg.335.1614100405394; Tue, 23 Feb 2021 09:13:25 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 23 Feb 2021 18:13:15 +0100 Message-ID: To: Nikita Popov Cc: "G. P. B." , PHP internals Content-Type: multipart/alternative; boundary="0000000000004ba32105bc040933" Subject: Re: [PHP-DEV] Interaction between finally blocks and exit() From: guilliam.xavier@gmail.com (Guilliam Xavier) --0000000000004ba32105bc040933 Content-Type: text/plain; charset="UTF-8" On Tue, Feb 23, 2021 at 5:12 PM Nikita Popov wrote: > On Tue, Feb 23, 2021 at 4:52 PM Guilliam Xavier > wrote: > >> On Fri, Feb 5, 2021 at 2:10 PM G. P. B. 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 >> > >> >> Hello again, >> >> From my message from two weeks ago, my understanding is that finally >> blocks >> are *never* supposed to be executed on exit(), and that there is indeed a >> bug (regression) with generators. >> >> With PHP 8.0.3RC1 having been released without any reply here from the >> people CCed, maybe you should open a bug report? >> > > Finally blocks are intended to be always executed when destructors are > executed. The fact that they are not yet executed for exit() outside > generators is a known bug. (For generators, finally is part of the > destructor, which is why the issue does not appear there.) > > Regards, > Nikita > Thanks for replying. So it seems that I had it all backwards ^^' For the record, this comment may help understanding: https://github.com/php/php-src/pull/5243#issuecomment-598664651 -- Guilliam Xavier --0000000000004ba32105bc040933--