Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83311
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pthreads.org from 209.85.192.176 cause and error)
MIME-Version: 1.0
In-Reply-To: <54E74ADF.9040608@googlemail.com>
References: <CAL=_i_mdb1GvYFZr1ZEqvCgZ3+um-ZYuz5xAFZuwjwBcXsEk3Q@mail.gmail.com>
	<54E5F77D.9090406@fischer.name>
	<CA+9eiLurXVtk0eKAuKF8uUb=6SVqZtatXSvZ9bnvW1gnb0hz4A@mail.gmail.com>
	<54E6F48A.9040906@fischer.name>
	<CAPwsocEiTSOM0EtFR52KNFCZNYG4dDguuyvNpk5kMKaRDwOZCA@mail.gmail.com>
	<CAL=_i_m4gUy081cMM4Aw5St4OYxVfAXK0hDZ_fSR-ChZc_UUow@mail.gmail.com>
	<54E72FE7.9030803@googlemail.com>
	<54E7312D.9090404@googlemail.com>
	<CAL=_i_m44Nbabgx56p_Lo9w5hCW-=MW3rvyh_2-B-bV7e3NkBQ@mail.gmail.com>
	<54E73E70.5020403@googlemail.com>
	<CAF+90c9gB67JfYG1M42YWSRLgENx3ixfghztJBN4okBRvyTCWQ@mail.gmail.com>
	<54E74ADF.9040608@googlemail.com>
Date: Fri, 20 Feb 2015 15:29:42 +0000
Message-ID: <CAL=_i_nEpEhuahRcekoH=dBm9BQd2HTFGfqPjduNzGa+wpTuoA@mail.gmail.com>
To: Crypto Compress <cryptocompress@googlemail.com>
Cc: PHP Developers Mailing List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1134259ab343b5050f86b8bf
Subject: Re: [PHP-DEV] [VOTE] Expectations
From: pthreads@pthreads.org (Joe Watkins)

--001a1134259ab343b5050f86b8bf
Content-Type: text/plain; charset=UTF-8

> However I think it is pre
mature to vote on as there was (sorry) not explicit discussions about
it.

I haven't heard that from anyone else, the RFC is plenty old.

> A couple of things are unclear. See the numerous questions in this thread.
> I also do not like other things.

These don't seem like valid reasons to hold off progress.

> zend.assertions:

Having a more general debug setting might be a good idea, but is outside of
the scope of this RFC.

> assert.exceptions:

Delay isn't necessary, exceptions are not used by default, and there is
plenty of time for Engine Exceptions to make necessary changes.

Cheers
Joe

On Fri, Feb 20, 2015 at 2:55 PM, Crypto Compress <
cryptocompress@googlemail.com> wrote:

> Am 20.02.2015 um 15:09 schrieb Nikita Popov:
>
>> On Fri, Feb 20, 2015 at 3:02 PM, Crypto Compress <
>> cryptocompress@googlemail.com <mailto:cryptocompress@googlemail.com>>
>> wrote:
>>
>>
>>         AssertionExceptions are not intended to be caught, they are
>>         intended to be seen, in a specific environment.
>>
>>
>>     Joe, your argumentation is around how (not) to use exceptions. I
>>     can see your point and it's valid.
>>     My point is about not to implement exceptions at all.
>>
>>     If exceptions are not intended to be caught, they don't need to be
>>     thrown (even if the context is different).
>>     If exceptions are not thrown and not caught, we can use "error" in
>>     dev and some easing severity (warning, zero cost nothing) in prod.
>>
>>     Freely adapted from Murphy: If assertion exception can be catched,
>>     it will be even in production.
>>
>>
>> The point behind AssertionException is that
>> a) It will leave the scope where with the failed assertion immediately. A
>> warning would continue running the code, even though some precondition is
>> violated, which doesn't make sense.
>>
>
> Assumed context is wrong here.
> - exception in development: error
> - no exception in production: warning, zero cost nothing
>
> Rephrased: A zero-cost non-existing exception would continue running the
> code, ...
>
> In a previous email you brought up the point if or not derive AssertionEx
> from Exception. I argue that all child exception MUST BE derived from
> Exception. Any exception to this is not an Exception. (my english is too
> limited to explain this, sorry)
>
>
>  b) It can still be gracefully handled (unlike a fatal error). E.g. the
>> unit testing framework can catch it, so you can continue running all your
>> tests even if one causes an assertion failure.
>>
>
> Unit test frameworks do this already. No change here.
>
>
>  When Joe says "not intended to be caught" this is referring to "normal"
>> code. Catching them at the top-level still makes sense, e.g. for the unit
>> testing case mentioned or even just to print a nice error message with
>> extra information. Using an exception instead of a fatal error also means
>> that things like "finally" will still run, so your code can still release
>> locks etc even if an assertion failure occurred.
>>
>
> In production this will never happen. We go round in circles here. I am
> aware of you preference on "exceptions everywhere".
>
>
>
>> Nikita
>>
>
>

--001a1134259ab343b5050f86b8bf--