Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:69608 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 38630 invoked from network); 17 Oct 2013 12:31:51 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 17 Oct 2013 12:31:51 -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:20189] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 67/95-12663-7B8DF525 for ; Thu, 17 Oct 2013 08:31:51 -0400 To: internals@lists.php.net,Michael Wallner Message-ID: <525FD8B3.8090701@php.net> Date: Thu, 17 Oct 2013 13:31:47 +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> In-Reply-To: Content-Type: text/plain; charset=UTF-8; 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 01:01 PM, Michael Wallner wrote: > On 17 October 2013 13:45, Sebastian Krebs wrote: > >> While tinking about it: As assertions are a way to describe conditions, >> that are valid _in every case_ (or else the application is unrecoverable >> broken), it is somehow different from just "exeptional cases", that may be >> recovered during runtime. Therefore I'd prefer "the hard with" with errors >> and such. I think they are somehow comparable to compile-errors, but during >> runtime. Or with a "LogicException", that isn't simply (and without side >> effects) solveable by replacing the value of one variable with another one. > > I tend to see it the same way. I think PHP's assert is derived from > C's assert, where ASSERT(3) says: > > "... assert() prints an error message to standard error and terminates > the program by calling abort(3) if expression is false ..." > > Where the important part is "terminates the program". > > > -- off topic -- > > What I'd love to see, though, would be conditional execution of the > assert block, i.e. if ASSERT_ACTIVE!=true, the expression wouldn't > even be evaluated. So it were usable with expressions instead of > strings in production code. I guess, accepting a callable as first > argument could more or less solve this wish now that we've got > closures... > Sorry Mike, you'll get this twice, just to keep everyone updated ... By default, php's assert implementation will just generate a warning. By default, this implementation throws an exception, resulting in abortion of execution if the exception is not handled ... I'm still thinking about disabling compilation of the expression ... I'm not sure it's practical ... Cheers