Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69637
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CABXB=RTU=m-Ugkkk1gqa_HXRV_K7dPL3CEuyzDtY+EwQ8mD=aw@mail.gmail.com>
References: <D7.A0.22512.AE09F525@pb1.pair.com>
	<525FC834.4060501@php.net>
	<CAMUwpuRHpAB6ut8CZ2TJJF0oJJ7B1QfSP_+Nfv3sda=QoyWb-A@mail.gmail.com>
	<1534105.bNC2os93J1@rofl>
	<CALJZF3h75yw2=mETjyZz1=005XmwX1K2wHujfRMufu3QBL_rrg@mail.gmail.com>
	<525FDAC3.6060103@php.net>
	<CABXB=RTU=m-Ugkkk1gqa_HXRV_K7dPL3CEuyzDtY+EwQ8mD=aw@mail.gmail.com>
Date: Thu, 17 Oct 2013 17:51:29 +0200
Message-ID: <CAF+90c-s-tanQoYV+AzkjxWJ_crJPPxT4HJg4dfnaFMfx5i4gA@mail.gmail.com>
To: J David <j.david.lists@gmail.com>
Cc: Joe Watkins <krakjoe@php.net>, PHP internals <internals@lists.php.net>, 
	Michael Wallner <mike@php.net>
Content-Type: multipart/alternative; boundary=089e01536de8893e8604e8f1ca06
Subject: Re: [PHP-DEV] Assertions
From: nikita.ppv@gmail.com (Nikita Popov)

--089e01536de8893e8604e8f1ca06
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Oct 17, 2013 at 5:39 PM, J David <j.david.lists@gmail.com> wrote:

> Assertions have three defining characteristics:
>
> 1) They are (potentially inefficient) checks run in
> debug/non-production that completely disappear when run in production.
> 2) When they pass, they produce no side effects.
> 3) When an assertion fails, which can only ever happen in
> debug/non-production, the program dies.
>
> Each component of this triad interacts with the others to make
> assertions something different than the other tools in the debugging
> toolbox, which is why they have value.
>
> Talking about catching exceptions thrown by an assertion failure seems
> very contrary to that, because even if PHP is hardcoded to completely
> ignore everything between "assert" and ";" when parsing in production,
> any attempt to catch assertion-related exceptions won't get the same
> treatment and will still be present in the production code.  This can
> cause a change in behavior, particularly in the case of catching all
> exceptions, and encourages the generation of side effects (like trying
> to recover an error) from an assertion test which will no longer be
> performed when assertions are disabled for production.
>

Nobody is arguing that assertions should be used as a control-flow
structure. It's still most useful to implement them as exceptions. Apart
from being a lot better integrated than fatal errors (in particular they
have such fancy things like stacktraces...) exceptions can also be
gracefully handled where necessary. E.g. PHPUnit will catch the exception
and tell you that an assertion failed, but it will still be able to
continue running the rest of the testsuite. A framework (or front
controller in general) can easily catch the exception at the top level and
display an appropriate debugging page (rather than doing ugly
register_shutdown_function hacks that are necessary to have even remotely
graceful handling of fatals). A deamon or server will be able to process
further requests, even if one particular had an assertion failure.
Assertions shouldn't be used for control flow, but it should still be
possible to handle them gracefully. Exceptions offer that, fatals do not.

Nikita

--089e01536de8893e8604e8f1ca06--