Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62025
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAH-PCH7874id459NTuMqL6pzL=feRtaWUAiPiSqPDa73tnFy9w@mail.gmail.com>
References: <CAH-PCH7874id459NTuMqL6pzL=feRtaWUAiPiSqPDa73tnFy9w@mail.gmail.com>
Date: Sat, 4 Aug 2012 00:47:25 +0200
Message-ID: <CAF+90c_R7D3OC5ubzOAw46E3hoPdeyOYD5H2vXU5Uy_CqirOVg@mail.gmail.com>
To: Ferenc Kovacs <tyra3l@gmail.com>
Cc: PHP Internals <internals@lists.php.net>, Andrew Faulds <ajf@ajf.me>, 
	Stan Vass <sv_forums@fmethod.com>, Etienne Kneuss <colder@php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] Error handling brainstorming
From: nikita.ppv@gmail.com (Nikita Popov)

On Fri, Aug 3, 2012 at 10:55 PM, Ferenc Kovacs <tyra3l@gmail.com> wrote:
> 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.

I think there are several types of errors in PHP that have to be
handled differently:
 * There are "debugging" class errors, like notices etc. They are
normally programming mistakes, but don't really prevent further
execution of the script. Those should stay as they are. Throwing
exceptions here would make things more complicated for the caller.
 * There are real errors, which should actually stop execution, but
which currently don't because throwing a fatal error would be overkill
due to it's incatchability (and even recoverable fatals are hard to
catch). Many warnings fall into this category. E.g. if a function is
called with incorrect parameters (e.g. too little of them) then an
E_WARNING is thrown. The wrong function call is clearly an error, but
PHP chooses to continue execution there. In my eyes this is a mistake
and these cases should be exceptions. (As exceptions are easily
catchable one can combine the best of both worlds here).
 * There is a small number of recoverable fatal errors. Those are
obviously the clearest candidates for exceptions, because recoverable
fatal *is* basically an exception with very ugly catching.
 * There are a large number of fatal errors in places which aren't
really fatal. They probably should be recoverable fatals now, and as
such exceptions in the future.
 * There is a small number of truly fatal errors, i.e. some kind of
problem deep in the engine. There is probably no way to turn those
into exceptions.
 * Another special category are parse and compilations errors. Those
are not inherently fatal (e.g. a parse error in an eval() does not
have to stop script execution), but they would be really hard to turn
into exceptions with the current architecture.

To summarize, what I'd like to see:
 * Not-really fatal errors (and currently recoverable fatal errors) to
be converted into exceptions
 * Some of the warnings be converted to exceptions (depends on the
exact context).
 * Leave notices etc alone.

Nikita