Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:69671 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 26558 invoked from network); 18 Oct 2013 12:10:42 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 18 Oct 2013 12:10:42 -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:1098] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E5/60-23638-04521625 for ; Fri, 18 Oct 2013 08:10:41 -0400 To: internals@lists.php.net,J David Message-ID: <5261253D.1050306@php.net> Date: Fri, 18 Oct 2013 13:10:37 +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> <5260D11C.90406@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/18/2013 12:35 PM, J David wrote: > 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! > You are talking about the current implementation of assert as if it is an actual implementation of assert, and it is not. This leads me to think you didn't actually look at the manual, or the current implementation, before you started to reel about how assert should and does work - even though, it doesn't. So I think I see what you are worried about, catch all blocks ?? seriously ?? we are meant to prepare for that ?? Julien I responded too, I don't know if he agrees or not, but I've given him a good explanation of why we should use exceptions. Mike: PHP's assert is not derived from C, or isn't deployed as such; by default it is a way to generate E_WARNING's, which is the wrong default for an implementation of assert. Furthermore, it's a serious restriction that you can only use string assertions, one that cannot be worked around from an extension. Sebastian: That's what assert does in C, it's not useful to exit from a PHP program without at least the opportunity to deal with the error, usually that means an error page, or some kind of action, but not necessarily continuing with execution. In C a coredump can be generated and that it useful to the prgorammer, in PHP we have no such thing, we must have the option to hand back control, the old implementation does this with callbacks and this implementation with catch blocks. Rowan: it is not our responsibility to prepare Zend for bad programmers; catching all is a horrible horrible thing to do, I don't think we should be encouraged to restrict what the engine can do in preparation for poor programming. I didn't mean to be rude, I meant to be to the point, I don't actually have the time to sit here and write 5 essays a day, to a single individual, to explain what should be obvious. I realise this implementation breaks some compatibility, how much is retained is open for discussion, if we can just stop talking about what assert is meant to be or what it isn't meant to be. It is what we make it, and we are replacing an implementation, so if you used assertion and callbacks before, you need an option to do the same thing and catch happens to cover it. I really don't know why you are talking about breaking compatibility and aborting execution without recourse in the same breath ... I think some are thinking that we are implementing access to actual assert() functionality, we are not doing that, we are implementing a higher level assert, suitable in PHP, for PHP. Cheers Joe