Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83301
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <54E73E70.5020403@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>
Date: Fri, 20 Feb 2015 15:09:32 +0100
Message-ID: <CAF+90c9gB67JfYG1M42YWSRLgENx3ixfghztJBN4okBRvyTCWQ@mail.gmail.com>
To: Crypto Compress <cryptocompress@googlemail.com>
Cc: PHP Developers Mailing List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=e89a8f3ba35d0ae6e0050f859ae4
Subject: Re: [PHP-DEV] [VOTE] Expectations
From: nikita.ppv@gmail.com (Nikita Popov)

--e89a8f3ba35d0ae6e0050f859ae4
Content-Type: text/plain; charset=UTF-8

On Fri, Feb 20, 2015 at 3:02 PM, Crypto Compress <
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.
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.

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.

Nikita

--e89a8f3ba35d0ae6e0050f859ae4--