Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:107528 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 80923 invoked from network); 13 Oct 2019 12:25:48 -0000 Received: from unknown (HELO php-smtp3.php.net) (208.43.231.12) by pb1.pair.com with SMTP; 13 Oct 2019 12:25:48 -0000 Received: from php-smtp3.php.net (localhost [127.0.0.1]) by php-smtp3.php.net (Postfix) with ESMTP id 68C182D19CA for ; Sun, 13 Oct 2019 03:09:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp3.php.net X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,KHOP_HELO_FCRDNS, SPF_HELO_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: X-Spam-Virus: No Received: from mail.netwake.de (srv2.netwake.de [IPv6:2a01:4f8:c0c:a10::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp3.php.net (Postfix) with ESMTPS for ; Sun, 13 Oct 2019 03:09:24 -0700 (PDT) Received: from M-DE-010.fritz.box (unknown [IPv6:2a04:4540:1604:1e00:b4a8:9367:c32c:1740]) (Authenticated sender: thomas.lamy@netwake.de) by mail.netwake.de (Postfix) with ESMTPSA id 56667269CE2 for ; Sun, 13 Oct 2019 12:09:22 +0200 (CEST) To: internals@lists.php.net References: <76F6996C-F254-47C3-AAD6-3338F38F30C6@gmail.com> Message-ID: <5f7035cc-bfb1-4ba5-3fda-4a9526fae86b@netwake.de> Date: Sun, 13 Oct 2019 12:09:21 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <76F6996C-F254-47C3-AAD6-3338F38F30C6@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Envelope-From: Subject: Re: [PHP-DEV] exit() via exception From: thomas.lamy@netwake.de (Thomas Lamy) Am 11.10.19 um 15:16 schrieb Claude Pache: > >> Le 11 oct. 2019 à 13:05, Nikita Popov a écrit : >> >> I'm mainly wondering how exactly we'd go about integrating this in the >> existing exception hierarchy. Assuming that it is desirable to allow people >> to actually catch this exception, my first thought would be along these >> lines: >> >> Throwable (convert to abstract class) >> \-> Exception >> \-> Error >> \-> ExitThrowable >> >> This does mean though that existing code using catch(Throwable) is going to >> catch exit()s as well. This can be avoided by introducing *yet another* >> super-class/interface above Throwable, which is something I'd rather avoid. > > We should keep the semantics of `exit`, which is quite akin an early `return` in a function. Therefore: > > * Executing finally blocks (as does an early `return`) would be an improvement. > > * But intercepting it in a `catch` block or in an exception handler, is usually unwanted, contrarily to everything that currently implements `Throwable`. > > But if you do want to allow exit signals to be caught in catch blocks, there is no absolute necessity to introduce yet another superclass or superinterface, because you can write (since PHP 7.1): > > catch (\Throwable | \ExitSignal $e) > > —Claude This! +1 Tom