Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62021
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
In-Reply-To: <501C3D0D.8050904@ajf.me>
References: <CAH-PCH7874id459NTuMqL6pzL=feRtaWUAiPiSqPDa73tnFy9w@mail.gmail.com>
	<501C3D0D.8050904@ajf.me>
Date: Fri, 3 Aug 2012 23:44:46 +0200
Message-ID: <CAH-PCH5WrvG0c3JRrS4t6B3NJ99K0EPkhgc_nPPw17GR19S4aA@mail.gmail.com>
To: Andrew Faulds <ajf@ajf.me>
Cc: PHP Internals <internals@lists.php.net>, Stan Vass <sv_forums@fmethod.com>, 
	Etienne Kneuss <colder@php.net>
Content-Type: multipart/alternative; boundary=20cf3071c710cc3b6404c6636f3c
Subject: Re: Error handling brainstorming
From: tyra3l@gmail.com (Ferenc Kovacs)

--20cf3071c710cc3b6404c6636f3c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Aug 3, 2012 at 11:05 PM, Andrew Faulds <ajf@ajf.me> wrote:

>  On 03/08/12 21:55, Ferenc Kovacs wrote:
>
> 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?
>
> Warnings aren't "errors" as such (IMO they are little more than glorified
> debugging print statements). Making them into exceptions would mean you'd
> have to catch them, whilst at the moment they are loud but harmless.
>

errors and warnings/notices/etc. share the same infrastructure(called error
handling. :P) so it is a little bit easy to get confused when someone talks
about error handling in generals by errors, or only just a subset of the
error levels.


> However, I think more serious errors should be exceptions. But perhaps in
> PHP 6, because obviously this would break a lot of things.
>

okay, then it is clear.


>
>
>  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,
>
> By that I thought you meant errors of the kind E_STRICT, not warnings.
> Misunderstanding.
>

I was referring to notices/warnings, sorry for the confusion.
But it seems from your reply that you take E_STRICT messages as errors?
Why? Those can only happen on successful operations, and until 5.4, they
weren't part of E_ALL, so they are the less known and less serious of all
of the error levels.


>
>  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.
>
> Of course. I think they are something the current errors system should
> remain for. It should be for that kind of thing, but proper "errors" (you
> know, things going wrong, not warnings etc.) should be exceptions, I thin=
k.
>

Yeah, errors are meant to be explicit, hard to not notice/handle and for
that description, Exceptions works just fine.


>
>  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 cod=
e
> 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, a=
nd
> 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.
>
>  Truly fatal errors can't become exceptions. But some fatal errors
> shouldn't be fatal and are recoverable (and I think these should become
> exceptions).
>

yeah, this is in line with what I said.

... skip the links ...

To sum up my thoughts:
> - "real" (i.e., things going wrong, code doing something bad) errors
> should become exceptions, with the possible exception of fatal errors tha=
t
> it is impossible to recover from
>

I think that is the further where can we go without breaking every code out
there.


> - notices, warnings, deprecations, etc. should stay as PHP errors, so you
> can just suppress them if you want, and they don't require you to handle
> them
>

I'm thinking about some kind of new infrastructure which would allow the
developer to handle/fetch the errors locally (similar to how you can fetch
the last error with error_get_last(), but with the ability to fetch
multiple items and only those which were generated for a given piece of
code.
of course we could still keep the set_error_handler() as I see two
different use case for handling warnings:

   1. you want to log all errors in some other format what the log_errors
   and error_log ini directives provide
   2. you want to get the errors/warnings in the same scope where the error
   occured and you want to handle that error in that context

for 1, the current set_error_handler is perfect (maybe some improvements
would be welcome, like having multiple handlers at the same time as we
allow it for spl_autoload_register, etc.), for 2, it would be nice having a
better infrastructure, currently it isn't as easy to fetch the warnings for
a specific operation as it could be.


> So fatal errors and notices/warnings/deprecations stay errors, everything
> else becomes an exception.
>
> Clear?
>

yep.

ps: in the meantime we discussed with you on IRC, and it seems that after
that, you would also put E_STRICT to the warnings group.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--20cf3071c710cc3b6404c6636f3c--