Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69600
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.50 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAMUwpuSG9GF8kC6BkULmcG+KYvdm6gubQN36B2D2NFi5235qmg@mail.gmail.com>
References: <D7.A0.22512.AE09F525@pb1.pair.com> <CAMUwpuSG9GF8kC6BkULmcG+KYvdm6gubQN36B2D2NFi5235qmg@mail.gmail.com>
Date: Thu, 17 Oct 2013 12:54:43 +0200
Message-ID: <CALtuQzCTezSwFOAeNmr3MnYW6QU=bSTMtm1K6EqCCL6tuvbhug@mail.gmail.com>
To: Julien Pauli <jpauli@php.net>
Cc: Joe Watkins <krakjoe@php.net>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b624e2a9341a004e8eda787
Subject: Re: [PHP-DEV] Assertions
From: krebs.seb@gmail.com (Sebastian Krebs)

--047d7b624e2a9341a004e8eda787
Content-Type: text/plain; charset=ISO-8859-1

2013/10/17 Julien Pauli <jpauli@php.net>

> 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>
> >
> >         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.
>

Me too. And yes, I really use assertions.


> 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.
>

Because assertions (or at least the resulting error) should be disabled in
production I'd be fine with an error too.


> 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
>



-- 
github.com/KingCrunch

--047d7b624e2a9341a004e8eda787--