Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69607
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.179 as permitted sender)
MIME-Version: 1.0
Sender: julienpauli@gmail.com
In-Reply-To: <525FC834.4060501@php.net>
References: <D7.A0.22512.AE09F525@pb1.pair.com> <CAMUwpuSG9GF8kC6BkULmcG+KYvdm6gubQN36B2D2NFi5235qmg@mail.gmail.com>
 <525FC834.4060501@php.net>
Date: Thu, 17 Oct 2013 14:01:27 +0200
Message-ID: <CAMUwpuRHpAB6ut8CZ2TJJF0oJJ7B1QfSP_+Nfv3sda=QoyWb-A@mail.gmail.com>
To: Joe Watkins <krakjoe@php.net>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c3d3f443084c04e8ee9660
Subject: Re: [PHP-DEV] Assertions
From: jpauli@php.net (Julien Pauli)

--001a11c3d3f443084c04e8ee9660
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Oct 17, 2013 at 1:21 PM, Joe Watkins <krakjoe@php.net> wrote:

> On 10/17/2013 11:51 AM, Julien Pauli wrote:
>
>> On Thu, Oct 17, 2013 at 9:25 AM, Joe Watkins <krakjoe@php.net> wrote:
>>
>>  Morning All,
>>>
>>>          I'd like to draw some attention to how poor assertions are in
>>> PHP.
>>>
>>>          The current assertion API is not usable in my opinion; it has a
>>> considerable overhead, relies on eval(), and is generally poorly
>>> implemented.
>>>
>>>          I have done some work toward implementing assert at the Zend
>>> level, giving assertions a more modern, usable feel to them.
>>>
>>>          https://github.com/krakjoe/****php-src/compare/assert<https://github.com/krakjoe/**php-src/compare/assert>
>>> <https:/**/github.com/krakjoe/php-src/**compare/assert<https://github.com/krakjoe/php-src/compare/assert>
>>> >
>>>
>>>
>>>          This implementation of assert removes the old implementation and
>>> associated functions and INI settings, and replaces it with a single INI
>>> setting to control assertion compilation.
>>>
>>>          Failed assertions throw an AssertionException (which extends
>>> ErrorException with a severity of E_ERROR), setting the message of the
>>> exception to the expression asserted.
>>>
>>>          The syntax of assertion is the same as [all] other languages:
>>>
>>>          T_ASSERT expr ';'
>>>
>>>          This means that assert("some code here") will pass assertion
>>> causing no error, because strings are no longer treated as code, because
>>> eval is evil();
>>>
>>>          Setting zend.assertions=0 system configuration setting will stop
>>> ZEND_ASSRT compilation.
>>>
>>>          So, we have:
>>>
>>>          try {
>>>                  assert (PHP != JUNK);
>>>
>>>
>>>          } catch(AssertionException $ex) {
>>>                  printf("Assertion failed: %s\n", $ex->getMessage());
>>>                  printf("Something is horribly wrong ...\n");
>>>          }
>>>
>>>          Better, no ??
>>>
>>
>>
>> I like the idea.
>> However, there is always the debatte about if a Core feature should throw
>> an Exception or generate an error.
>> In our current system, they don't throw Exceptions but generate errors.
>> Also : someone could use a callback, and then make them throw exceptions
>> if
>> he wants to ; the callback on assertion fail, which IMO is a good feature,
>> has dissapeared in your patch.
>>
>> Julien.Pauli
>>
>>  Morning Julien,
>
>         That was brought up in IRC yesterday, someone pointed out that
> generators throw exceptions in some places (from an object method, but
> still). So it's not unprecedented, and nobody has provided reason for the
> preference to use errors over exceptions ... however, general case aside:
>
>         Throwing exceptions here makes much more sense than errors, and is
> the reason there is no need for callbacks; should you need to control the
> flow of execution or take some action because of a failed assertion you can
> catch the AssertionException and do that without cluttering ini and module
> globals in order to do it.
>
>         In general, of course, an assertion should abort execution, that's
> a bit final for PHP and runs contrary to carry-on-executing-no-matter-**what,
> which we like, on the interweb. But, should you need to take some action
> and stop that exception from bubbling to the surface you should do that
> with language constructs try/catch rather than dated callbacks, which don't
> give you the same kind of recovery options so easily, they additionally
> require a new scope, a new function entry, module globals for support, and
> ini settings to configure ...
>
>         That being said, I would rather reimplement the ability to invoke
> a callback than scrap the idea all together ... but might we have something
> a bit more PHP5 ??
>
>         assert(
>                 $expression != false ||
>                 (CONSTANT_MASK & HAS_BITS),
>                 function(){
>                         echo "oh rly?"; }
>         );
>
>         I still think it's a bit unnecessary, and this:
>
>         try {
>                 assert($expression != false ||
>                         (CONSTANT_MASK & HAS_BITS));
>
>         } catch (AssertionException $ex) {
>                 echo "oh rly?";
>         }
>
>         Makes much more sense ... I would rather encourage or even require
> that than reimplement callbacks ... they only seemed to exist to service
> the current implementation.
>

This makes sense.

However, I still continue to think that assertions should stay assertions,
aka : run time fatal errors when enabled.
For me, there is nothing to "catch", except the fact that the program has
stopped somewhere, it tells you where, and why, and you have to fix it :
that's an assertion (for me).
Enabling or disabling it with an INI setting is just all right.

Having assert() with exception makes the code much more heavy for me.

<?php

assert(MYCONST == "bar");
foo();

In the code above, I dont expect to catch any exception. Like in C, where
usually assert() is just a macro bound to some #define , I want assertion
to clearly be as invisible as possible when I disable them.
With a catch, that make the code look heavier.

Those were my opinions :-)


Julien.Pauli

--001a11c3d3f443084c04e8ee9660--