Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62019
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.170 as permitted sender)
MIME-Version: 1.0
Date: Fri, 3 Aug 2012 22:55:56 +0200
Message-ID: <CAH-PCH7874id459NTuMqL6pzL=feRtaWUAiPiSqPDa73tnFy9w@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Cc: Andrew Faulds <ajf@ajf.me>, Stan Vass <sv_forums@fmethod.com>, Etienne Kneuss <colder@php.net>
Content-Type: multipart/alternative; boundary=20cf3071c71022383404c662c19e
Subject: Error handling brainstorming
From: tyra3l@gmail.com (Ferenc Kovacs)

--20cf3071c71022383404c662c19e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

We started a discussion about the current error handling mechanism and the
possible improvements in the "Why do disabled functions / classes generate
a WARNING" thread[1], but that is a little bit offtopic there, so I decided
to create a separate thread for it.
Basically Etienne mentioned that the original issue was a good example why
would we reconsider throwing exceptions from the core, which is currently
discouraged.[2]
Stan replied with the idea of turning the current error handling mechanism
in php into using Exceptions for everything, but keeping some error types
as is/uncatchable. [3]
This was brought up on the lists multiple times, we even have two separate
RFC with similar idea.[4][5]
I tried to explain why I think is impossible to achieve the same
functionality by turning the php errors into exceptions without a major
overhaul in the engine[6][7], but it seems that I failed to do so.

First of all, I would like to clear up the few misunderstandings:

Stan:
You mentioned that E_STRICT (and E_ERROR but I see no problem with that)
should be instant fatal error, I think that was only a typo on your part,
could you please clear that up?
I would also ask you to confirm that you would like to see every error
levels[8] turned into exceptions except the non-recoverable ones. It seems
that you and Andrew disagree on that.

Andrew:
From your mails, it seems that you don't agree with Stan on turning
everything but fatals into exceptions[9].
I'm really confused about that, as if we take away warnings (and by that
logic everything else which is less serious than a warning) the we would
only have the fatal errors (which we already discussed to not turn into
exceptions and you also seemed to agree[10]), E_USER
and E_RECOVERABLE_ERROR.
Is this what you propose?

My opinion (and this is what I tried to explain to you) is that it is
pretty common in the core and the bundled extensions to raise notices and
warnings left and right, and still do something,
If we would turn anything less serious than E_RECOVERABLE_ERROR (so any
notice, deprecation notice, strict notice or warning)into an exception,
that would be a huuuuuuge BC break.
Basically silecing errors through setting error_reporting level, custom
error handlers or the @ operator would stop working, and one should put
everything into a try-catch block to not have his code blown into his code
constantly.
Another thing that I mentioned: even if you catch everything, there would
be some things that you couldn't do anymore.
Any method which throws notices or strict/deprecated notices or warnings
would be broken, as the execution would be halted (as the execution jumps
into the catch) which would be a major PITA to the userland developers, and
without further work, it could make the userland/engine in a more fragile
state, as the original call was interrupted but the execution still
continues from a different spot.
With the current error handling the execution either resumes after the
error handler is called, or the execution is terminates gracefully

The current error handling provides a way to trigger multiple
errors/warnings for an operation, and allows to still return and continue
the execution.
Turning everything into exceptions would kill both of those, and without
providing something similar suite, we can't do that imo.

So basically these are our boundaries:

   - Fatal errors can't be turned into Exceptions, but it was mentioned
   multiple times, that there are some fatals, which could be turned into
   E_RECOVERABLE_ERROR.
   - Most/all non-fatal errors could be safe to be turned into Exceptions
   as without explicit measures(try-catch) on the caller's side, it would
   still stop the execution.
   - Every other warning/notice/etc. which are just holds additional
   information but not indicating unsuccessful execution in itself cannot b=
e
   turned into Exceptions.

I have a few ideas about how to proceed from here, but I need some time to
gather my thoughts.

   1. http://www.mail-archive.com/internals@lists.php.net/msg60043.html
   2. http://www.mail-archive.com/internals@lists.php.net/msg60054.html
   3. http://www.mail-archive.com/internals@lists.php.net/msg60056.html
   4. https://wiki.php.net/rfc/errors_as_exceptions
   5. https://wiki.php.net/rfc/enhanced_error_handling
   6. http://www.mail-archive.com/internals@lists.php.net/msg60060.html
   7. http://www.mail-archive.com/internals@lists.php.net/msg60063.html
   8. http://www.php.net/manual/en/errorfunc.constants.php
   9. http://www.mail-archive.com/internals@lists.php.net/msg60061.html
   10. http://www.mail-archive.com/internals@lists.php.net/msg60065.html

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--20cf3071c71022383404c662c19e--