Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:69774 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 52118 invoked from network); 22 Oct 2013 18:07:16 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 22 Oct 2013 18:07:16 -0000 X-Host-Fingerprint: 80.4.21.210 cpc22-asfd3-2-0-cust209.1-2.cable.virginm.net Received: from [80.4.21.210] ([80.4.21.210:5488] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 46/89-10840-3DEB6625 for ; Tue, 22 Oct 2013 14:07:16 -0400 To: internals@lists.php.net,Adam Harvey Message-ID: <5266BECD.8000204@php.net> Date: Tue, 22 Oct 2013 19:07:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 References: <3D.BC.23638.84CA1625@pb1.pair.com> <5264FE65.8050808@php.net> <5266B6A8.4010607@pthreads.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Posted-By: 80.4.21.210 Subject: Re: [PHP-DEV] RFC: Expectations From: krakjoe@php.net (Joe Watkins) On 10/22/2013 06:56 PM, Adam Harvey wrote: > On 22 October 2013 10:32, Joe Watkins wrote: >> On 10/22/2013 06:20 PM, Adam Harvey wrote: >>> I agree that something to replace the eval-based assert() would be >>> good. What if the new syntax simply respected assert_options(), and >>> assert_options() was extended to support an explicit ASSERT_EXCEPTION >>> control option (that presumably took an exception class name as its >>> option value)? That seems like it would provide the exception based >>> possibilities that some posters want while maintaining the same >>> assertion behaviour that users are already used to by default. >> >> I'm a bit perplexed at the need to retain any compatibility with what is a >> poor implementation ? > > To be fair, I think part of the disconnect here is that I don't feel > like the current implementation is particularly poor besides the > eval-based API. I don't really want an assertion failure to throw an > exception — if I did, I'd use an assert callback or ErrorException to > do that. I want it logged so I can look at it later, and that's easily > configured with the current assertion setup. > > I guess I'm wondering if there's a middle ground here, rather than > throwing the assertion baby out with the bathwater in favour of an > entirely new thing that could simply be syntax sugar sprinkled over an > existing, working implementation. > > Adam > You can catch exceptions, and log them. You can do that without impacting everything around you, you can do that, or whatever else you like. There is one camp saying we want to catch exceptions and have access to stack traces and the current scope, others who say that there is no need and the application can quit, now some who say they want to log ... There is no need for any of this to go on at the level of the implementation, it is a restriction on the implementation to do so. I can't stress enough how important it is that, used correctly, the impact of assertion during development is completely removed at runtime in production, completely removed, not by any voodoo, but by core software o+. That is of paramount importance for the ideal implementation, and we have that right now, there is no convincing reason to let it go. Cheers Joe