Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107501
To: internals@lists.php.net
References: <CAF+90c9EQ+UGe-y+V_n1QrYkXtPh1uWKXXWEJQUe0xP-MjV7_w@mail.gmail.com>
Date: Fri, 11 Oct 2019 13:31:48 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <CAF+90c9EQ+UGe-y+V_n1QrYkXtPh1uWKXXWEJQUe0xP-MjV7_w@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Subject: Re: exit() via exception
From: marandall@php.net (Mark Randall)
Message-ID: <php.internals-107501@news.php.net>

On 11/10/2019 12:05, Nikita Popov wrote:
> 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.

If it is caught, could the exit() potentially be cancelled by not 
re-throwing it?

What about a hidden catch block that is inserted at compiler level?

try {
   exit();
}
catch (\Throwable) {
   ...
}

Would become:

try {
   exit();
}
catch (\ExitThrowable $ex) {
   throw $ex;
}
catch (\Throwable) {
   ...
}

The hidden catch block would be overwritten with a user catch block if 
one existed that caught \ExitThrowable, and it would be *required* to 
re-throw it, otherwise it would be done automatically at the end of the 
code segment or upon encountering a return etc.

It's obscure though, it hides things, and I don't think I like it.

Adding another level of throwable is fugly, but it's by far the most 
initiative IMO. But take the initiative and prohibit it from being used 
by itself so we don't end up in the same position a few years down the line.

try {

}
catch (\TopLevelThrowableForSureThisTime $ex) {

}

^^ Compiler Error.

Mark Randall