Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70563
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.50 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAF+90c-UpBkvUThNYRN2P1+_Wc9pLjTpnoM43NeHkOPaqCuLAA@mail.gmail.com>
References: <CAF+90c9Hxzi_JhyZkyi6Ly9zxWjgFsCBsvgzH7a8n-ce3kPKYw@mail.gmail.com>
	<bf72a3b3f08321543979442e053092fb@mail.gmail.com>
	<CAF+90c9jDnOrUqOGsbuqRFDWHX_xZsegVsrgN_5XOXYU8U14rg@mail.gmail.com>
	<CAPgLKihoqsmrXVPXSxVJS3y4oSfY7AtCVk9B-r+P6xV1Ov_R_Q@mail.gmail.com>
	<CABDNdAERsmDSuDtzy0PHpMzUfh0W6+oziNdRNKPZabaWjofJ9A@mail.gmail.com>
	<CABDNdAF10=Zv08de68poX6_s-5vMAZHRj9bWhupyfzXxqdwGyA@mail.gmail.com>
	<f28de2fc2bb258924714379195852565@mail.gmail.com>
	<CABDNdAGAmhL_wTQkXUKSibqcX3++WYm68B6K7n2ysrigUYbApw@mail.gmail.com>
	<6dc040b1d4917ab616951694d3f37575@mail.gmail.com>
	<CAF+90c-UpBkvUThNYRN2P1+_Wc9pLjTpnoM43NeHkOPaqCuLAA@mail.gmail.com>
Date: Mon, 9 Dec 2013 13:10:17 -0500
Message-ID: <CABDNdAG8mdBeDj6zWaCA_C-+FKvRpJgAzLie-MPE5KVuhwiYRw@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Zeev Suraski <zeev@zend.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] [VOTE] Allowing use of exceptions in the engine
From: pjsturgeon@gmail.com (Philip Sturgeon)

On Mon, Dec 9, 2013 at 11:41 AM, Nikita Popov <nikita.ppv@gmail.com> wrote:
> On Mon, Dec 9, 2013 at 5:22 PM, Zeev Suraski <zeev@zend.com> wrote:
>>
>> For me it is an argument.  Instead of being able to handle these errors in
>> the same way they handle all other errors, now they have to learn new
>> syntax and concepts.  I see no reason to change the status quo, which
>> allows those who want exceptions to easily convert errors to thrown
>> exceptions, into a state where those who don't want to use exceptions are
>> forced to use them.  Again, it's entirely fair that we disagree...
>
>
> You can't convert fatal errors to exceptions using an error handler. That's
> why I'm targeting fatal errors here and not all errors in general. While I'm
> not a big fan of PHP's error system in general, it's easy enough to turn
> warnings or notices into exceptions via error handlers. But for fatal errors
> that's just not possible.
>
> To achieve what I want it would be enough to turn fatal errors into
> recoverable fatal errors, that would already allow the error handler
> approach. But that's a lot harder to do (and imho less usable) than directly
> using exceptions. Keeping the engine stable after an exceptions is
> relatively simple, the same can't be said about recoverable fatals.
>
> Regarding the "forcing OO concepts": As Philip pointed out, unless you
> already make use of try/catch a fatal error and an uncaught exception are
> about the same to the end user - actually, an uncaught exception is just a
> special fatal error. I could totally understand your concerns - if this
> discussion weren't about fatal errors. E.g. changing a warning to an
> exception would cause lots of issues. The @ operator would stop working and
> people would be forced to use try/catch. But for fatals @ never worked in
> the first place. You can't handle them right now. Changing them to
> exceptions adds the ability to handle them via try/catch, but of course you
> don't need to do them. You can let them bubble (and in most cases that's
> what you should do) and let them effectively act the same way as a fatal
> error currently does, just with a bit of a different message ;)
>
> Thanks,
> Nikita

Right. Put simply:

1. Users who previously did not care about exceptions will continue to
not care about exceptions, and do not have to do anything any
differently.
2. Users who want to handle fatal errors somehow (because you
currently cannot) can use this to catch them.

Nobody needs to work with exceptions if they dont want to, that fatal
error just shows up as a uncaught backtrace and fatals errors just
like it used to.

Seems like a win win.