Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:69664 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 87047 invoked from network); 18 Oct 2013 06:11:44 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 18 Oct 2013 06:11:44 -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:16530] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A5/38-43111-F11D0625 for ; Fri, 18 Oct 2013 02:11:44 -0400 To: internals@lists.php.net,J David Message-ID: <5260D11C.90406@php.net> Date: Fri, 18 Oct 2013 07:11:40 +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 07:06 PM, J David wrote: > On Thu, Oct 17, 2013 at 1:33 PM, Nikita Popov wrote: >> Similarly, showing a friendly debugging page when an assertion fails does >> not seem to go against your idea of assertions. > > You may be using asserts to test much too complicated concepts. > > Assertions are a *very* low-level feature. The classic example of an > assert is to check that expectations are valid in some function that > gets called in a loop 20,000,000 times and takes 6 minutes to run if > you check the conditions and 3 seconds if you don't. > > If you are using assert to check that the session data is valid or > that the MySQL connection is valid or something, that's not good. If > there's an error message, it wasn't an assertion. If it's > recoverable, it wasn't an assertion. > >> It just changes the >> presentation form to simplify debugging the cause by specifying additional >> information that is known to the framework (but not to the assertion >> itself). >> >>> >>> Why do we need a new way to throw an exception? >>> >>> Why do we need to mess up another tool that has a different purpose to do >>> it? >>> >>> What's wrong with writing the three-line function one time to get the >>> behavior you want? >> >> >> Those questions have a very simple answer: You can't disable code throwing >> exceptions ;) Assertions can be disabled. > > No, the code that throws "assertion exceptions" can be disabled. The > code that catches them cannot. > > The value that assertions provide is the independent error handling > channel. If you do not want the value that assertions provide, don't > use them. > > If you want to make that error handling channel more robust and > useful, go nuts, that would be great. > > If you want disable-able exception checks that can be skipped based on > a global setting, and for some reason testing the global setting > before testing the condition and throwing the exception is offensive > to you, find a good name for this new feature and propose that. > > But please don't screw up existing code for people that use assertions > properly by redefining them as exceptions. > > The behavior you're describing is trivial to implement at the user > level, and it's still not clear why it belongs in the language core or > why it needs to alter other, different, existing behavior. > > Thanks! > Assertions in PHP are whatever we implement them to be, there isn't really any low level features in PHP, it's a high level programming language where you would not expect to find any. By default, a failed assertion in PHP results in an E_WARNING being raised, this is not "using assertions properly", this is just generating warnings. Assertions, written originally for PHP4, are currently supported by other user land functions, module globals, callbacks and ini settings. You can only evaluate strings, you cannot use actual expressions, you cannot use anonymous functions. We are not implementing assert() as it is in C, we are implementing an assert() that is useful in PHP5. One that does not require user land functions, module globals and a bunch of ini settings. One that does allow you to use expressions, and annonymous functions. You have been provided very good rationale for the use of exceptions to handle failed assertions, we'd all be grateful if you could stop derailing the conversation. Cheers Joe