On 04/04/2019 16:17, Sara Golemon wrote:
I would say that any exception thrown in (1) should lead to an non-zero
exit since the program has violated an invariant assumption.
The problem with enforcing an exception contract at runtime is surely
how to avoid the cure being worse than the disease.
The behaviour most consistent with the current language would be to
throw an Error - this is what happens for other invariant violations
like "null passed where an array was expected". But that doesn't really
make any sense here: it would mean wrapping a meaningful exception in a
generic UnexpectedExceptionError and then throwing it again, at code
that's still not expecting it.
An immediate fatal error would be more practical, but I'm not sure what
benefit it would bring. If the calling code has no way of catching the
exception, it will eventually blow through the stack and become a fatal
error anyway; but if it would eventually reach a catch block, what value
is added by making it fatal immediately instead?
For instance:
function foo(): type nothrow {
throw new SomethingException; // or, more likely, fail to catch one
from a deeper call
}
function bar(): type throws ( SomethingException ) {
throw new SomethingException;
}
try {
foo();
bar();
} catch ( SomethingException $e ) {
log($e);
}
The program can clearly cope with a SomethingException and carry on; but
because the author of foo() didn't fully test their code, it has no
chance to and is killed outright instead.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
