Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:47445
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain daevel.fr designates 188.165.152.122 as permitted sender)
Message-ID: <4BA78611.9070805@daevel.fr>
Date: Mon, 22 Mar 2010 16:00:33 +0100
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100307 Icedove/3.0.3
MIME-Version: 1.0
To: internals@lists.php.net
References: <98b8086f1003220751j73a8414es89b9b469c46f6630@mail.gmail.com>
In-Reply-To: <98b8086f1003220751j73a8414es89b9b469c46f6630@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [PATCH] Raise warning first on "Maximum execution time
 exceeded"
From: php-dev.list@daevel.fr ("Olivier B.")

Hi,

well, maybe we should provide a better behaviour for all fatal errors, no ?
A frequent one I see is the fatal error for calls like "$obj->method()", 
when $obj is not an object.

Isn't possible to allow catching of fatal errors, like other errors ?

Olivier

On 22/03/2010 15:51, troels knak-nielsen wrote:
> Hi list.
>
> We log all errors that happens in our production environment, but as
> fatal errors can't be handled from within php, we end up with little
> information to go on for further debugging. I'm not very familiar with
> the php internals code, but I managed to throw in a hack that appears
> to work. In the handler function for timeouts (zend_timeout), I raise
> a WARNING, sleep for 1 second and then resume normal behavior, which
> results in a fatal error. This gives userland code 1 second to log the
> error somewhere, which should be sufficient for debugging.
>
> Would like to get feedback as to if this has any hidden problems, but
> otherwise I propose that it's included in the project.
>
>