Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83307
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 74.125.82.179 as permitted sender)
Message-ID: <54E74ADF.9040608@googlemail.com>
Date: Fri, 20 Feb 2015 15:55:27 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: PHP Developers Mailing List <internals@lists.php.net>
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>
In-Reply-To: <CAF+90c9gB67JfYG1M42YWSRLgENx3ixfghztJBN4okBRvyTCWQ@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------070108010606050502030702"
Subject: Re: [PHP-DEV] [VOTE] Expectations
From: cryptocompress@googlemail.com (Crypto Compress)

--------------070108010606050502030702
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

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


--------------070108010606050502030702--