Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69641
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.171 as permitted sender)
MIME-Version: 1.0
Sender: jdavidlists@gmail.com
In-Reply-To: <CAF+90c_=e=8iwr7n3PVVKtbEPniGem0fYpn5NtHf6LjJzEZ5iA@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>
	<CAF+90c-s-tanQoYV+AzkjxWJ_crJPPxT4HJg4dfnaFMfx5i4gA@mail.gmail.com>
	<CABXB=RS_eDxTRmTqqPzwqhAcCH6BLjx82kNV3rafWiJXqocA1A@mail.gmail.com>
	<CAF+90c_=e=8iwr7n3PVVKtbEPniGem0fYpn5NtHf6LjJzEZ5iA@mail.gmail.com>
Date: Thu, 17 Oct 2013 13:03:37 -0400
Message-ID: <CABXB=RRGUf6dX=CfzkgH94-yf_1E565wDmh412KXtPo-w2=x5Q@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Joe Watkins <krakjoe@php.net>, 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)

On Thu, Oct 17, 2013 at 12:12 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:
> I would greatly appreciate a more detailed explanation as to how these
> examples abuse assertions.

All three use the failure of an assertion to alter the flow of
execution of the program.  Essentially you wrote, "Nobody is arguing
that assertions should be used as a control-flow structure" and then
provided three examples of using assertions to do exactly that.

All three cause unexpected behavior if the asserted condition is not
true and assertions are disabled because the condition was not
evaluated.

In all three of those examples, the behavior you want is easily
obtained by throwing an exception.

In fact, what some people might do in those situations is:

assert($myObject->internalState == OBJECT_STATE_VALID, "internal
object state not valid");
if ($myObject->internalState != OBJECT_STATE_VALID)
  throw FMLException("internal object state not valid");

(In this case, you would probably do the PHPUnit stuff with assertions
disabled.)

Assertions are a debugging/development check designed to facilitate
proof of correctness.  They are not present or used in production
code.  There is no danger that a failed assertion will ever cause a
production app to abort.  They serve one purpose, which is to bring
things to a screeching halt when somethat that should never, ever
happen has happened.  And their value comes *because* they are
independent of methods used to handle potentially-recoverable errors.

Why do we need a new way to throw an exception?

Why do we need to mess up another tool that has a different purpose to do it?

What's wrong with writing the three-line function one time to get the
behavior you want?

It's totally reasonable to tie in to the stack-trace generating code
to provide as much information as possible about why an assertion
failed, similar to what exceptions do.  But assertions must not be
catchable through any normal mechanism, and the minute code execution
resumes after a check fails, that check is absolutely a control-flow
structure, and it is not an assertion.

Thanks!