Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:69670 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 23831 invoked from network); 18 Oct 2013 11:40:52 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 18 Oct 2013 11:40:52 -0000 Authentication-Results: pb1.pair.com header.from=jdavidlists@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=jdavidlists@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.179 as permitted sender) X-PHP-List-Original-Sender: jdavidlists@gmail.com X-Host-Fingerprint: 209.85.223.179 mail-ie0-f179.google.com Received: from [209.85.223.179] ([209.85.223.179:58585] helo=mail-ie0-f179.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F1/00-23638-34E11625 for ; Fri, 18 Oct 2013 07:40:52 -0400 Received: by mail-ie0-f179.google.com with SMTP id aq17so6487234iec.10 for ; Fri, 18 Oct 2013 04:40:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=mx/+0Jl2qV85g5NoMOR2fDdG8rLG1hu35MaJCWF3YII=; b=Yzft4O8JKyR2vRnBWFNZFl3s1TrDyIfpJuXWtB11Zjkt8EsEFeZLneoknO9ytAzGHl MO/ikKVoqVz09vhfipnSCTeCfT73ZqNFEshAb1ia3aTQoUjQzLjPa0pGNtIJfma959Zu G+iziecrPmI3GP6/GiqzcQOozbewsfT7bZP809vUnH0JYPy1nXLTowLrE/vpHgoJmzLc O+Po6calewg63dDl3wEIGoiFI9OtQcBwbG7uI9Qfn4yFd1PfUjx54Idiz/6vpcXW2hS/ sLF2tARTmtw3VC7KuNvh3WXMqZWp7o/hPR1+6gCc0esY8orGSxqVdyYnFaCuH/lRZlE5 FsdA== MIME-Version: 1.0 X-Received: by 10.50.107.70 with SMTP id ha6mr1729787igb.60.1382096140123; Fri, 18 Oct 2013 04:35:40 -0700 (PDT) Sender: jdavidlists@gmail.com Received: by 10.43.180.131 with HTTP; Fri, 18 Oct 2013 04:35:40 -0700 (PDT) In-Reply-To: <5260D11C.90406@php.net> References: <525FC834.4060501@php.net> <1534105.bNC2os93J1@rofl> <525FDAC3.6060103@php.net> <5260D11C.90406@php.net> Date: Fri, 18 Oct 2013 07:35:40 -0400 X-Google-Sender-Auth: BtkQBKQBXNURMwD5Boio_ilA_qQ Message-ID: To: Joe Watkins Cc: PHP internals Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [PHP-DEV] Assertions From: j.david.lists@gmail.com (J David) On Fri, Oct 18, 2013 at 2:11 AM, Joe Watkins wrote: > 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. Wow. Well, if you speak for everyone on this subject then go ahead and implement it. Break all existing code everywhere that uses assert() and catches all exceptions. But: On Thu, Oct 17, 2013 at 6:51 AM, Julien Pauli wrote: > However, there is always the debatte about if a Core feature should throw > an Exception or generate an error. On Thu, Oct 17, 2013 at 7:45 AM, Sebastian Krebs wrote: > Actually if an assertion fails it means, that the application is totally > broken and cannot get recovered. The use case you describe is more like > "validation". > This means, that even if it throws an AssertionException, when you are able > to catch it and recover the process, it means, that "assert" was the wrong > choice On Thu, Oct 17, 2013 at 8:01 AM, Michael Wallner wrote: > 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". On Thu, Oct 17, 2013 at 5:42 PM, Rowan Collins wrote: > Reading through the discussion, I think this point may deserve more > prominence: the problem with throwing an exception is that it is possible > (and probably quite common) to have a catch block which catches *all* > exceptions. Throwing an exception from assert() tangles up any handling you > did want to do for failed assertions with the presumably rather different > handling you want to do for runtime exceptions. are you sure you speak for "all" and that merely expressing an dissenting opinion is "derailing the discussion?" The feature you want is a useful new feature. The only feedback I am offering you is to please consider adding it without breaking existing features, for example by calling it "expect" or "validate" instead of "assert." The word "assert" is not innately magic. Put "see also 'expect'" in the documentation of assert and if your functionality is truly better in all cases, people will naturally move from assert to expect and eventually maybe assert can be deprecated if PHP is really such a high-level language where it is not appropriate to have. The only effect of calling this new functionality "assert" is to break existing code. Not to mention that since this approach does not break BC, doing it this way may allow the implementation of this feature sooner from a release standpoint. Likewise, if you separately want to enhance the diagnostic value of the existing assert functionality without breaking existing code, that would also, I believe, be most welcome. But I don't pretend to speak for all so I cannot say for sure. If your response is "No, you are wrong because I say so," then so be it. You may rely on my lack of further participation in the discussion, per your request. Thanks!