Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105085
To: internals@lists.php.net
References: <CAHN63oMjO-7cdnF55Mrj-MxVrq9mvm5=c2M681CuXLkE_Hez_A@mail.gmail.com>
 <CAESVnVpcTTC-77EjLgH-9jwbPgzaR2x_JV+D00SMffWKgU=bkw@mail.gmail.com>
 <CAHN63oP4p-VdK=J3L3vi0GygHawRq5KkCHJEF0tFoQBtSezGiQ@mail.gmail.com>
 <CALKiJKrbcv42cyWYqLfizzNVGc55Z4qEW+X6gfxzoVENSrnZuw@mail.gmail.com>
 <CAHN63oOfR3DD9b_xHLPUh20=jJFQTJH+Qce298k-4vm6X4bdKg@mail.gmail.com>
 <65AF9E1E-DFA6-47AE-952B-9ABEBD9B6038@gmail.com>
 <CAHN63oMqOgCgh6voyL0sjXQJEnMKQ=NJ+MXQuU0355EG8Apffw@mail.gmail.com>
 <CAHN63oMz1YM5c0V7QLGOJ=1LKEasMuHVxwsdbrxC==5Up6=mMQ@mail.gmail.com>
 <284d1f9f-03d3-1488-77dd-82e18edf9f4c@gmail.com>
 <CAHN63oOqx9AxU=ofAQceKEQoJqYTuku1AWGa-sw=BLMTMP0Vjw@mail.gmail.com>
 <db94829a-3ffb-998b-08cd-67eb36ea4cc2@gmail.com>
 <CAFPFaMK5hs3y5VziAnqDjM1sz3-RLvQUgUj0gQYuxshbd_rFGA@mail.gmail.com>
 <CAHN63oOZ6x6PEOJo=u9gVR-5f+87sD7jpwKnw7kKiohf3LSDLg@mail.gmail.com>
 <3144F5D1-1F18-4C42-9B3E-AF1B1E598E47@koalephant.com>
 <CAESVnVqC+WkyCGp+EOUP_FVpbR2avoyVoRTXBLh5B0TiogykBA@mail.gmail.com>
Message-ID: <917cb7bc-4abc-4bae-1a5a-b2ba1777fa55@gmail.com>
Date: Thu, 4 Apr 2019 21:43:58 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <CAESVnVqC+WkyCGp+EOUP_FVpbR2avoyVoRTXBLh5B0TiogykBA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] Question about adding !function_identifier
From: rowan.collins@gmail.com (Rowan Collins)

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]