What about a new keyword in addition to "catch"?
(exact keyword would be up for discussion)
try {
}
catchExit ($exit) {
}
Or, how far would we get if we do not make this catchable, and
(perhaps) not run any "finally" block?
Could this already solve some of the technical problems, without
breaking existing expectations?
On Fri, 11 Oct 2019 at 14:32, Mark Randall <marand...@php.net> wrote:
>
> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
