Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:69677 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 36553 invoked from network); 18 Oct 2013 12:46:02 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 18 Oct 2013 12:46:02 -0000 Authentication-Results: pb1.pair.com smtp.mail=tyra3l@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=tyra3l@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.169 as permitted sender) X-PHP-List-Original-Sender: tyra3l@gmail.com X-Host-Fingerprint: 209.85.223.169 mail-ie0-f169.google.com Received: from [209.85.223.169] ([209.85.223.169:52493] helo=mail-ie0-f169.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id D6/82-23638-98D21625 for ; Fri, 18 Oct 2013 08:46:02 -0400 Received: by mail-ie0-f169.google.com with SMTP id ar20so6522976iec.0 for ; Fri, 18 Oct 2013 05:45:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=vaGT+DXtmfbmN0pK6B+faPaqvLFsnPVgTuAyrJOm5f8=; b=NNje2/FkRLY32CiE/hYAszHmAYB/GkbgKbxwPyYTUkhLmGl9WZiGm1BmK4bIUMMdwj uJWdvCnQWOGYkVH4ErwB1TorIdE7S9lqht8yLwMlQkfKNZRISK00F7RENHOWVkT/2R1l 4nsr2Pm8Omc0e5OgpboycRkLuRtZjLekwLEVkY0ZEHfc8K8z6SVUj/eGvceXA+pD7/es MM0fDv/qRAOSuhnaNKFeReelD04/DFaJuERjRBE1DqlWcUOv9tJw+bxygfUu7Bc4AXy7 tIKZJ1b6GRp8cqz/7xBNHtogoBx/3SZHMpeS7OoCEzCJABHW+IaR540OYK7iWP+ql7nR 0zzg== MIME-Version: 1.0 X-Received: by 10.42.172.67 with SMTP id m3mr1684865icz.21.1382100358957; Fri, 18 Oct 2013 05:45:58 -0700 (PDT) Received: by 10.50.73.42 with HTTP; Fri, 18 Oct 2013 05:45:58 -0700 (PDT) In-Reply-To: <52612942.1090707@pthreads.org> References: <525FC834.4060501@php.net> <1534105.bNC2os93J1@rofl> <525FDAC3.6060103@php.net> <5260D11C.90406@php.net> <52612942.1090707@pthreads.org> Date: Fri, 18 Oct 2013 14:45:58 +0200 Message-ID: To: Joe Watkins , PHP Internals , J David Content-Type: multipart/alternative; boundary=90e6ba6e8370f0939104e903501f Subject: Re: [PHP-DEV] Assertions From: tyra3l@gmail.com (Ferenc Kovacs) --90e6ba6e8370f0939104e903501f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Oct 18, 2013 at 2:27 PM, Joe Watkins wrote: > On 10/18/2013 01:15 PM, Ferenc Kovacs wrote: > > > > > On Fri, Oct 18, 2013 at 1: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 t= o >> > 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 total= ly >> > broken and cannot get recovered. The use case you describe is more lik= e >> > "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 handlin= g >> 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! >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> Hi, > > Personally I think that your argument was solid, and I'm fairly sure > that there are a bunch of code out there with your usecase: > > try{ > // call a bunch of functions, which in turn calls a bunch of functions, > etc. > // where one of the functions uses assert() > } catch(Exception $) { > // report some generic error somewhere, or retry the calls a couple of > times before bailing out > // or do nothing, or throw a different exception with or without settin= g > the previous exception to it > } > > those kind of code would potentially swallow/silence the assert violation > or potentionally show a different error scenario what really happened, an= d > leave the developer confused how can he see that kind of error when the > same code works in production (where the assertions don't run). > > using exceptions would also be less flexible than the current solution, > where you killed assert_options, so introduced a BC break for everybody > using that. > > I also agree that maybe the new one should be added instead of replacing > the current(hence keeping BC), and later (when we have some feedback, and > maybe extended the new way with some of the old options) can decide to > deprecate the "old" assert infrastructure. > > -- > Ferenc Kov=C3=A1cs > @Tyr43l - http://tyrael.hu > > The catch all argument is only valid when we are talking about migration, > and it's only an issue because we are supported a kind of backward > compatibility by accepting strings - even though there is no need to acce= pt > strings, at all. > > So would it be better then to break compatibility in that way, by removin= g > the ability to eval string expressions from the new implementation such > that migrating users of the current implementation cannot fall into the > catch all trap because their assertions will pass ?? > > Assert options are only there to service the current implementation of > assertion, the function can be added and generate an E_DEPRECATED, you ar= e > looking at a working, work in progress not a final implementation of the > idea. > > I don't like the idea of naming it something else, because it isn't > something else, and that will just be confusing, it is a re-implementatio= n > of assert at the language level. I'd rather break compatibility in some > graceful way, or emulate it, than confuse anyone ... > > Cheers > Joe > > agree, but we either have to keep BC(if we want it in the next minor version), or provide an easy migration path(if we want it in the next major version). keeping the name but changing the behavior in a way, which would require a major code review or removing all assertions which was written with the old behavior(to make sure you don't have assert_options() call or asserts in catch all blocks) would be really a bad thing, it would present us as changing things for the shake of change, and it could even slow/halt adoptation of the new version. --=20 Ferenc Kov=C3=A1cs @Tyr43l - http://tyrael.hu --90e6ba6e8370f0939104e903501f--