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

Reply via email to