Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70557
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <6dc040b1d4917ab616951694d3f37575@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>
Date: Mon, 9 Dec 2013 17:41:23 +0100
Message-ID: <CAF+90c-UpBkvUThNYRN2P1+_Wc9pLjTpnoM43NeHkOPaqCuLAA@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: Philip Sturgeon <pjsturgeon@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0141a79c9db78504ed1caaaa
Subject: Re: [PHP-DEV] [VOTE] Allowing use of exceptions in the engine
From: nikita.ppv@gmail.com (Nikita Popov)

--089e0141a79c9db78504ed1caaaa
Content-Type: text/plain; charset=ISO-8859-1

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

--089e0141a79c9db78504ed1caaaa--