Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69674
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.170 as permitted sender)
Message-ID: <52612910.5090900@gmail.com>
Date: Fri, 18 Oct 2013 13:26:56 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: internals <internals@lists.php.net>
References: <D7.A0.22512.AE09F525@pb1.pair.com>	<525FC834.4060501@php.net>	<CAMUwpuRHpAB6ut8CZ2TJJF0oJJ7B1QfSP_+Nfv3sda=QoyWb-A@mail.gmail.com>	<1534105.bNC2os93J1@rofl>	<CALJZF3h75yw2=mETjyZz1=005XmwX1K2wHujfRMufu3QBL_rrg@mail.gmail.com>	<525FDAC3.6060103@php.net>	<CABXB=RTU=m-Ugkkk1gqa_HXRV_K7dPL3CEuyzDtY+EwQ8mD=aw@mail.gmail.com>	<CAF+90c-s-tanQoYV+AzkjxWJ_crJPPxT4HJg4dfnaFMfx5i4gA@mail.gmail.com>	<CABXB=RS_eDxTRmTqqPzwqhAcCH6BLjx82kNV3rafWiJXqocA1A@mail.gmail.com>	<52601C6A.6020408@php.net>	<CABXB=RTLwLNevi2QANmaqo_x_heA55ExodJ9F2ZX_0fcTMDgqQ@mail.gmail.com>	<526059D2.5080109@gmail.com> <CAMauByWvCT41UqvJJ2CJ5-zRQOrdfLSAjTBa4sbXtmqiOTy7uQ@mail.gmail.com>
In-Reply-To: <CAMauByWvCT41UqvJJ2CJ5-zRQOrdfLSAjTBa4sbXtmqiOTy7uQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Assertions
From: rowan.collins@gmail.com (Rowan Collins)

On 18/10/2013 01:45, Marco Schuster wrote:
> On Thu, Oct 17, 2013 at 11:42 PM, Rowan Collins <rowan.collins@gmail.com> wrote:
>> The current implementation allows you to define a callback, and to choose
>> whether assertions are fatal, which means that unit test frameworks and
>> fancy-output wrappers can intercept assertions *without affecting other
>> parts of the code*. The only way to do that with catch blocks would be to
>> have an exception which didn't descend from Exception.
> You could always throw a secondary exception from the catch-block.

It's not so much a question of whether it would be *possible* to write 
code which handled such situations, as whether it is reasonable to 
*expect* people to do so: as soon as assert() started throwing 
exceptions, all code which uses assert() would have to be audited to see 
what catch blocks the AssertExceptions would fall into, and add extra 
boilerplate to explicitly re-throw them.

I agree with J David to the extent that whatever behaviour assert() 
should have, it should be *distinct* from other types of error checking. 
Having assertions be caught by a catch(Exception) block reduces that 
distinction while increasing the BC break.

Meanwhile, what is the actual case for catching the assertion in a code 
block rather than registering a failure callback? So far, it seems to be 
a case of "callbacks feel a bit old-fashioned" - the uses cases people 
have mentioned of Unit Tests and pretty debug output are both adequately 
covered by a simple callback. Is there a situation where you would, for 
instance, want to catch an AssertionException, do something, and then 
re-throw it to an outer block?

-- 
Rowan Collins
[IMSoP]