Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62452
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: <CAOWwgp=nWjh3swdSbpHEXFixq5zO_2NBUyJYBXyWjwE66K3Y=A@mail.gmail.com>
References: <CAH-PCH7874id459NTuMqL6pzL=feRtaWUAiPiSqPDa73tnFy9w@mail.gmail.com>
	<CAOWwgpk7VbQbuB7NPG6KR3P+63cmdP0npjr7VCHhwo+H3p7QJg@mail.gmail.com>
	<3E3A531D90FC43B8B7E9CDD37F1EEE40@pc>
	<CAOWwgp=nWjh3swdSbpHEXFixq5zO_2NBUyJYBXyWjwE66K3Y=A@mail.gmail.com>
Date: Fri, 24 Aug 2012 18:49:05 +0200
Message-ID: <CAKZjf5T5iA_6rN1wdmyd7AvNXi7kAWx6jJ0wjmErSuTGa1K70Q@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] Error handling brainstorming
From: alex.aulbach@gmail.com (Alex Aulbach)

2012/8/24 Nicolas Grekas <nicolas.grekas+php@gmail.com>:
>> **
>> The overall mood seems to be that since PHP has an error handler, everyone
>> is free to handle errors any way they want.
>> 2) When everyone starts handling errors in their own way with error
>> handlers, you can't reliably use third party code. You are in your own
>> universe.
>>
>
> I think that's the main point that makes any change to the way PHP
> currently handles errors difficult:
>
> The current behavior is to continue the execution flow (except for fatal
> errors of course) whereas an exception always breaks it. Throwing an
> exception, either in a custom or in a new internal handler, introduces a
> major portability + backward compatibility issue.


I think we should talk first over the general handling and then go
into the details (how to handle the different types of errors/warnings
etc.)

Maybe I repeat some things. What do we want?

A) Handling errors with exceptions instead error-handler
B) handling warnings/notices in some way.
That are 2 completely different things...

For A: Errors (something which stops execution) could be just handled
as an exception. I see no problem with this: If not handled, they
behave like now.



For B - the warnings etc. - I suggest something like this:

// This is pseudocode:

abstract class WarningAbstract implements Exception
{

   public function __construct()
   {
       error_log($this->message()......);
       unset($this); // I just want to say, that the exception is
destroyed in any way and so not handled any more
   }
...
}


// A warning looks like this - this is created by PHP for example when
turning on E_WARNING in php.ini

class Warning extends WarningAbstract
{
}

// and when created it does this:

if (class_exists('Warning')) {
  $warning = new Warning();
  if (isset($warning)) {
    throw $warning;
  }
}

Logically, when the exception is created the constructor is called. In
this example (by default) PHP could handle a warning etc. (write
something into a error-log) and then "destructs itself", to stop the
handling. (Of course this doesn't work now, when unseting myself the
object is not unseted; I wrote this code only so that PHP-programmers
could understands what I mean.)

[Not so important: could be configured like now. If E_WARNING is
turned on in the php.ini, PHP creates the default handler for this
class itself. If not, the class doesn't exists and so nothing happens.
Or I create my own Warning class, and implement my own way to handle
the warnings.]

This has the big advantage, that we don't need to care about the
mentioned different handling of the different type of errors (see
above: A, B). I think it is important, that the way how it is done is
for every kind of error the same.

Now the details:

A file-error is defined

abstract class FileHandlerWarningAbstract extends if exists Warning //
of course "if exists" is no PHP - just to explain that it should work
as a "hint" for the compiler to create the "hierarchy"
{
}

The code to create the exception needs to recursively look up: If no
FileHandlerWarning exists it must know the "hirarchy of it's abstract"
(in this case the Warning) and look if that class exists. And so on.

So you can handle file-errors different from all other warnings
without try/catch everything. Not perfect for now, and I think a
little bit too complicated, but this is a brainstorming.


-- 
Alex Aulbach