Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:69642 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 1700 invoked from network); 17 Oct 2013 17:20:47 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 17 Oct 2013 17:20:47 -0000 X-Host-Fingerprint: 80.4.21.210 cpc22-asfd3-2-0-cust209.1-2.cable.virginmedia.com Received: from [80.4.21.210] ([80.4.21.210:13742] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 1C/92-12663-E6C10625 for ; Thu, 17 Oct 2013 13:20:47 -0400 To: internals@lists.php.net,J David Message-ID: <52601C6A.6020408@php.net> Date: Thu, 17 Oct 2013 18:20:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 References: <525FC834.4060501@php.net> <1534105.bNC2os93J1@rofl> <525FDAC3.6060103@php.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 80.4.21.210 Subject: Re: [PHP-DEV] Assertions From: krakjoe@php.net (Joe Watkins) On 10/17/2013 05:06 PM, J David wrote: > On Thu, Oct 17, 2013 at 11:51 AM, Nikita Popov wrote: >> Nobody is arguing that assertions should be used as a control-flow >> structure. It's still most useful to implement them as exceptions. Apart >> from being a lot better integrated than fatal errors (in particular they >> have such fancy things like stacktraces...) exceptions can also be >> gracefully handled where necessary. > > If it is useful to handle an assertion, then it wasn't an assertion. > The minute you talk about "handling" assertions they become a control > flow structure and cease to be assertions. > >> PHPUnit will catch the exception and tell you that an assertion failed, but it will still be able to continue running the rest of the testsuite. >> A framework (or front controller in general) can easily catch the exception at the top level and display an appropriate debugging page (rather than doing ugly register_shutdown_function hacks that are necessary to have even remotely graceful handling of fatals). >> A deamon or server will be able to process further requests, even if one particular had an assertion failure. > > Those are three great examples of how assertions are frequently misused. > > There are *many* cases where assertions are not useful. That means > use a different tool in those cases (like an exception), not that > assertions should be made into shorthand for exception throwing. > > That functionality is fine to have, just call it something else. > > Thanks! > The new implementation doesn't _require_ that you control the flow of execution but _allows_ you to, better than callbacks did. It is not practical to try and implement assert() as we know it in C, an aborted PHP program is not useful to the user, there is no coredump, there is nothing useful we can do other than pass control of execution back to the program where it is prepared to deal with it ...