Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83157
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.179 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAL=_i_=cY7TPzmsqhM5u+Hj8R+Q2UpD1uLmHaDh6dDGME98_7w@mail.gmail.com>
References: <CAL=_i_=cYXf=yjy7y6pytg7M=pe5z8dKpriqJiG2mC_XiMXYXw@mail.gmail.com>
	<54E1C24B.6010806@googlemail.com>
	<CAL=_i_kuuj-q6L0n4vZC2BC_D5Y_yKbmyDVXpSWrTSTXqDBGoA@mail.gmail.com>
	<CA+9eiLvT9JN08hMjN6mH_-WHvB4h5QeAKr7QMSvpz-FmrQGUhQ@mail.gmail.com>
	<CAF+90c_RDzXaLHuEHgZ9Bn6V-MnrnK4zA1PF+Rh_ijWpB4HrMA@mail.gmail.com>
	<CA+9eiLuDxRRXe7HWzqg7dNSiDzaPANk0sENMvr6y-1WVvrcLjQ@mail.gmail.com>
	<CA+9eiLs67UBr7DZ2QmUWSijih7bOPhHbqSu=gvVAPphQ5G-APQ@mail.gmail.com>
	<CAF+90c9hCf=85T9kZZViSPt=J+NbcGSv+z252ON20CSjo=RKPQ@mail.gmail.com>
	<CA+9eiLvOFBd+2SqEXF9D5cLyxK5s_ihqcX4SEVR62L1Jq5i1bw@mail.gmail.com>
	<CAL=_i_=cY7TPzmsqhM5u+Hj8R+Q2UpD1uLmHaDh6dDGME98_7w@mail.gmail.com>
Date: Thu, 19 Feb 2015 12:28:35 +0400
Message-ID: <CA+9eiLuQX+Dke_kA9H+KSMJ=FtR2dycWzYb-rcoJFak30iH6zQ@mail.gmail.com>
To: Joe Watkins <pthreads@pthreads.org>
Cc: Nikita Popov <nikita.ppv@gmail.com>, Crypto Compress <cryptocompress@googlemail.com>, 
	PHP Developers Mailing List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e01538610df85fb050f6cb80a
Subject: Re: [PHP-DEV] RFC: Expectations
From: dmitry@zend.com (Dmitry Stogov)

--089e01538610df85fb050f6cb80a
Content-Type: text/plain; charset=UTF-8

Hi Joe,

I think, we may just add additional vote question.
- If we like to custom exceptons as second argument?
but I don't care about it, so do as you like.

According to AssertException: add a note into Open Issues section.

e.g. we may introduce new abstract class BaseException
then make Excepton to be a child of BaseException
then introduce and use for assert AssertException (direct child of
BaseException)
All this changes are going to be implemented as part of Engine Exception
RFC.

And open the vote.

Thanks. Dmitry.



On Thu, Feb 19, 2015 at 10:58 AM, Joe Watkins <pthreads@pthreads.org> wrote:

> Morning,
>
> I hear the concern regarding custom exceptions. Things will be used badly
> whatever. It's easy to imagine that in a simple application you just don't
> need to specify custom exceptions. But in a large codebase, being able to
> structure exceptions is invaluable, it gives documentation reference points
> and makes stack traces easier to read at a glance, because they are more
> meaningful.
>
> So I think we should keep the ability to throw custom exceptions.
>
> I agree about making the exception part of a new tree, so that they are
> not caught, so I'll just wait for that from dmitry and open the vote.
>
> Cheers
> Joe
>
> On Wed, Feb 18, 2015 at 5:01 PM, Dmitry Stogov <dmitry@zend.com> wrote:
>
>>
>>
>> On Wed, Feb 18, 2015 at 5:44 PM, Nikita Popov <nikita.ppv@gmail.com>
>> wrote:
>>
>>> On Tue, Feb 17, 2015 at 10:50 PM, Dmitry Stogov <dmitry@zend.com> wrote:
>>>
>>>> Hi Joe
>>>>
>>>> The patch is ready https://github.com/php/php-src/pull/1088/files
>>>>
>>>> 1) I implemented AST pretty-printer to reconstruct the source. It may
>>>> be reused in Reflection and other places through
>>>>
>>>> ZEND_API zend_string *zend_ast_export(const char *prefix, zend_ast
>>>> *ast, const char *suffix);
>>>>
>>>> 2) zend.assertions=-1 - makes zero-cost asserts
>>>>
>>>> 3) assert() in a namespace leads to call a function defined in this
>>>> namespace (if it's defined), but zend.assertions is still may disable this
>>>> call or even prevent code generation for it. it's possible to use \assert()
>>>> to call the system function.
>>>>
>>>> Please, make update RFC, add notes about (2) and (3).
>>>> Then, it should be ready for voting.
>>>>
>>>> Nikita, please take a quick look over the patch. I hope, you don't have
>>>> objections.
>>>>
>>>
>>> I've added a few comments on the PR.
>>>
>>
>> Thank you very much. You found about 25 bugs :)
>> All of them except for "elseif" should be fixed now.
>> I also think printing "else if" instead of "elseif" is not a big problem.
>> Pretty-printer may also add or remove brackets in some situations.
>>
>>
>>>
>>> Two general notes on the RFC:
>>>
>>> 1. I don't like the ability to specify a different exception as the
>>> second param. Assertions are supposed to be used as sanity checks during
>>> development, not to throw meaningful and specialized exception types.
>>> Having this possibility will probably only encourage bad usage of assert().
>>> It's not a big problem to me, but I'd rather not have this "feature".
>>>
>>
>> Joe, this is part of your old patch. I really don't care about it.
>>
>>
>>> 2. Similar to the EngineExceptions RFC I'm wondering if
>>> AssertionException should extend Exception or be in a separate hierarchy.
>>> The same argument as with engine exceptions applies: It's pretty unlikely
>>> that you want to catch an AssertionException anywhere apart from top-level
>>> error handling code and that people using catch(Exception) blocks would
>>> accidentally catch assertions. I'm not sure I agree with this, but I wanted
>>> to mentioned the concern.
>>>
>>
>> This may be changed together with EngineException patch.
>> I started working on it, and I hope I'll show you results tomorrow.
>>
>> Thanks. Dmitry.
>>
>>
>>>
>>> Nikita
>>>
>>>
>>
>

--089e01538610df85fb050f6cb80a--