Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62020
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 64.22.89.133 as permitted sender)
Message-ID: <501C3D0D.8050904@ajf.me>
Date: Fri, 03 Aug 2012 22:05:17 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Ferenc Kovacs <tyra3l@gmail.com>
CC: PHP Internals <internals@lists.php.net>, 
 Stan Vass <sv_forums@fmethod.com>,
 Etienne Kneuss <colder@php.net>
References: <CAH-PCH7874id459NTuMqL6pzL=feRtaWUAiPiSqPDa73tnFy9w@mail.gmail.com>
In-Reply-To: <CAH-PCH7874id459NTuMqL6pzL=feRtaWUAiPiSqPDa73tnFy9w@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------040009040501070104060008"
Subject: Re: Error handling brainstorming
From: ajf@ajf.me (Andrew Faulds)

--------------040009040501070104060008
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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.
However, I think more serious errors should be exceptions. But perhaps 
in PHP 6, because obviously this would break a lot of things.
>
> 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.
> 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 think.
> 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.
>
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).
>
>   * 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 be 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
>
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 
that it is impossible to recover from
- 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

So fatal errors and notices/warnings/deprecations stay errors, 
everything else becomes an exception.

Clear?
> -- 
> Ferenc Kovács
> @Tyr43l - http://tyrael.hu


-- 
Andrew Faulds
http://ajf.me/


--------------040009040501070104060008--