Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69635
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.174 as permitted sender)
MIME-Version: 1.0
Sender: jdavidlists@gmail.com
In-Reply-To: <525FDAC3.6060103@php.net>
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>
Date: Thu, 17 Oct 2013 11:39:24 -0400
Message-ID: <CABXB=RTU=m-Ugkkk1gqa_HXRV_K7dPL3CEuyzDtY+EwQ8mD=aw@mail.gmail.com>
To: Joe Watkins <krakjoe@php.net>
Cc: PHP internals <internals@lists.php.net>, Michael Wallner <mike@php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] Assertions
From: j.david.lists@gmail.com (J David)

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.

If you want a concise easy-to-write test that throws an exception if
it's not true and runs in production code in catchable way that
doesn't abort the app, that is a great idea.  But it is not an
assertion.  It is also already easy to do.  Just write:

function Expect($shouldBeTrue, $message) {
  if (!$shouldBeTrue) throw new FMLException($message);
}

Expect($myObject->internalState == OBJECT_STATE_VALID, "object state
is not valid");

Customize as needed with your favorite exception type.

Maybe there is some reason why a variant of this should be in the
language core, although that's not immediately clear, but it seems
really hard to justify redefining the solid and well-understood
concept of assertions to do it.

Thanks!