Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:47447
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 83.243.58.134 as permitted sender)
To: "Olivier B." <php-dev.list@daevel.fr>
Cc: internals@lists.php.net
In-Reply-To: <4BA78611.9070805@daevel.fr>
References: <98b8086f1003220751j73a8414es89b9b469c46f6630@mail.gmail.com>
	 <4BA78611.9070805@daevel.fr>
Content-Type: text/plain; charset="UTF-8"
Organization: php.net
Date: Mon, 22 Mar 2010 16:09:17 +0100
Message-ID: <1269270557.1575.136.camel@guybrush>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [PATCH] Raise warning first on "Maximum execution
 time exceeded"
From: johannes@php.net (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

Hi,

On Mon, 2010-03-22 at 16:00 +0100, Olivier B. wrote:
> 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 ?

Fatal errors might let the engine in some undefined state. The only safe
thing we can do is terminate the current script. fror other cases we
have catchable fatal errors. Maybe there are a few more cases where
fatal errors can be made catchable fatal errors, but these are case by
case decisions.

johannes