Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69650
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.170 as permitted sender)
MIME-Version: 1.0
Sender: jdavidlists@gmail.com
In-Reply-To: <CAF+90c_=fGO3sA5TkDXVNGWaLENPmXo_GgL5jqYcZpxXxi9sWw@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>
	<CABXB=RRGUf6dX=CfzkgH94-yf_1E565wDmh412KXtPo-w2=x5Q@mail.gmail.com>
	<CAF+90c_=fGO3sA5TkDXVNGWaLENPmXo_GgL5jqYcZpxXxi9sWw@mail.gmail.com>
Date: Thu, 17 Oct 2013 14:06:03 -0400
Message-ID: <CABXB=RRSuoFzqex2thiiaR7LWG=4Z-eQAJ4tnajguMdBkemq7A@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 1:33 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:
> Similarly, showing a friendly debugging page when an assertion fails does
> not seem to go against your idea of assertions.

You may be using asserts to test much too complicated concepts.

Assertions are a *very* low-level feature.  The classic example of an
assert is to check that expectations are valid in some function that
gets called in a loop 20,000,000 times and takes 6 minutes to run if
you check the conditions and 3 seconds if you don't.

If you are using assert to check that the session data is valid or
that the MySQL connection is valid or something, that's not good.  If
there's an error message, it wasn't an assertion.  If it's
recoverable, it wasn't an assertion.

> It just changes the
> presentation form to simplify debugging the cause by specifying additional
> information that is known to the framework (but not to the assertion
> itself).
>
>>
>> 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?
>
>
> Those questions have a very simple answer: You can't disable code throwing
> exceptions ;) Assertions can be disabled.

No, the code that throws "assertion exceptions" can be disabled.  The
code that catches them cannot.

The value that assertions provide is the independent error handling
channel.  If you do not want the value that assertions provide, don't
use them.

If you want to make that error handling channel more robust and
useful, go nuts, that would be great.

If you want disable-able exception checks that can be skipped based on
a global setting, and for some reason testing the global setting
before testing the condition and throwing the exception is offensive
to you, find a good name for this new feature and propose that.

But please don't screw up existing code for people that use assertions
properly by redefining them as exceptions.

The behavior you're describing is trivial to implement at the user
level, and it's still not clear why it belongs in the language core or
why it needs to alter other, different, existing behavior.

Thanks!