Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69890
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.169 as permitted sender)
Content-Type: multipart/signed; boundary="Apple-Mail=_427CCA36-DD60-42F6-8E2C-142094DC0B03"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
In-Reply-To: <CAF+90c8hYvWcPKNDyDYStZvnfDf3o5jzdOihQdB=rGGUMicxwQ@mail.gmail.com>
Date: Sun, 27 Oct 2013 12:04:30 +0400
Cc: Adam Harvey <aharvey@php.net>,
 PHP internals <internals@lists.php.net>
Message-ID: <5303EB10-13DD-4DEB-9BF6-9CED215B8C70@gmail.com>
References: <CAF+90c8OgW4Nonaz+HQn+gi4r+AdaEMXsTxCAhn=WO-+aQQsZQ@mail.gmail.com> <CADajX4AWmpv_mVVGvsczmKoWyqdNOd+M51cNxmuSUfSXVqrQ_w@mail.gmail.com> <CAF+90c8hYvWcPKNDyDYStZvnfDf3o5jzdOihQdB=rGGUMicxwQ@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Exceptions in the engine
From: indeyets@gmail.com (Alexey Zakhlestin)

--Apple-Mail=_427CCA36-DD60-42F6-8E2C-142094DC0B03
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


On 27 =D0=BE=D0=BA=D1=82. 2013 =D0=B3., at 1:40, Nikita Popov =
<nikita.ppv@gmail.com> wrote:

> Reading through the mails in this thread a lot of people seem to have
> concerns about backwards compatibility. I can see where this comes =
from,
> "switch to using exceptions" certainly sounds like a seriously big BC =
break
> - but I don't think it actually is.
>=20
> Let's start by considering only E_ERROR (and leave recoverable fatals =
for
> later):

+1

> First of all we should establish that fatal errors do not occur during
> normal program execution. If you take your PHP 5.5 program and run it =
on
> PHP 5.6 (with E_ERROR converted to exceptions) you will see =
*absolutely no
> difference*. If you do, that means your code was previously throwing a
> fatal error already, i.e. it didn't actually work in the first place. =
Let
> me say this again, because I think it's important: If your code was =
working
> previously, it will continue working the same way after converting =
fatals
> to exceptions.
>=20
> But what happens when the program has a bug and does throw a fatal =
error?
> In this case the program already doesn't work, so what changes isn't
> particularly critical, but we should still consider it. There are =
basically
> two things that might happen:
>=20
> 1. Most likely everything will work just as you expect, the error will =
only
> be presented differently. Either because the exception is not handled =
and
> the message changes because of that (with stack trace) or an
> exception-handler or top-level catch-block handles it rather than the
> shutdown function and presents it in some different way. In either =
case
> this shouldn't matter - I certainly do hope that changing the look of =
an
> error is not considered a compatibility break...
> 2. A misplaced catch-and-ignore block catches the fatal error and =
dismisses
> it. This is of course unfortunate, but it's really not more than that. =
It's
> an inconvenience, yes, but it does not actually break anything. Some =
people
> have mentioned something about code-paths becoming reachable that were
> previous not, but I don't see how that applies. If you used a =
try/catch
> block, then you already expect that the code-path in the catch or the =
code
> after it may be taken. At this point I'd also like to point out that =
if
> code contains a catch-all block, it likely is also supposed to =
catch-all,
> so hiding the error is likely not even wrong. PHP never did Java's =
mistake
> of introducing checked exceptions, so PHP does not have a widespread
> pattern of "wrap everything with catch(Exception $e) to silence the
> compiler".

I think it is a good idea to avoid #2 altogether by introducing =
BaseException and using separate hierarchy for ex-fatal errors.
old code will ignore new exceptions and those will fall thru down to =
generic exception-handler and shutdown-handler

New code will be able to use `catch (BaseException $e)` but that should =
be deliberate decision by code-author

> So, that much on fatal errors. What about E_RECOVERABLE_ERROR?
>=20
> Here there may actually be BC issues. As already mentioned, =
recoverable
> fatals can currently be ignored with a custom error handler and =
exceptions
> make that impossible. So it might be that someone wrote an application =
that
> throws recoverable errors during "normal" program execution. I don't =
think
> that this is particularly realistic and as such I don't think this is
> really problematic, but others might see this differently. If that is =
the
> case it might become necessary to keep recoverable fatal errors as is.
>=20
> In conclusion, I don't see any non-negligible BC issues for the =
fatal-error
> change and only minor BC issues for the recoverable-fatal change (and =
even
> that can be dropped). As such I don't think pushing this off to PHP 6 =
is
> justified. I'd also like to point out that this RFC is a blocker for =
some
> of my other proposals. In particular, I don't think that I can in good
> conscience move the named arguments and argument unpacking RFCs =
forward
> without the ability to use exceptions. I would really hate to move =
named
> args off to PHP 6.

I think =E2=80=9Csafe" set of changes (E_ERROR + separate =
exceptions-hierarchy) should be implemented in 5.6.
Everything else should be planned for 6.x


--=20
Alexey Zakhlestin
CTO at Grids.by/you
https://github.com/indeyets
PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc




--Apple-Mail=_427CCA36-DD60-42F6-8E2C-142094DC0B03
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJSbMkaAAoJEMkJcRxZdR27dIgH/2hAsXtEC5OLD1o6m+T/A+XK
mJbU7O681hmsYtnMsQH9auoMZ/r9VCjndPeomeQvULEC5Ppsx9WdxkmtQA62D3YR
bFrzVVJpiusMbo1kUc5HIN/PAXDIDN93+jFJsZ9V+wa1H7/kJx4RMhMrZElSAJDT
+amaYtth/GfsXuEIJtSITAmZLeWGoz3Ejb3Vp+4vaNZk+eRKsABuhlwkxMzlq5NN
XfCO/METyY1iLVpK3vF6PS46TCdDxnvvAW9ZkYNrINeI0h70854804Hv6QmqrbZ6
6yy0+IwvriHhODncApV3LbH2M6kyLSgAkJHk3JYpcEffXsSH0nhDJsVPIjVjXgY=
=63nA
-----END PGP SIGNATURE-----

--Apple-Mail=_427CCA36-DD60-42F6-8E2C-142094DC0B03--