Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:47451
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.216 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        b=Te4dtp7nwfBu9NbP6AWDO+z58fzlEm1XXSA6UrQvdvSMpeHKMn7nlvWtzBsCIdqtNP
         oilz2k2VdZ0H3MLwbEan322BBtQlKyyjPjdh42nkgSQYxCYQ6wzmU4aKZKTZ7hZbSv3M
         LVly8i4rzeEHjJkAUfxlsbTnv0RGbphEPgw4A=
MIME-Version: 1.0
In-Reply-To: <1269270557.1575.136.camel@guybrush>
References: <98b8086f1003220751j73a8414es89b9b469c46f6630@mail.gmail.com>
	 <4BA78611.9070805@daevel.fr> <1269270557.1575.136.camel@guybrush>
Date: Mon, 22 Mar 2010 16:45:06 +0100
Message-ID: <b54d0abe1003220845v150358deq99419db17e2ffd7@mail.gmail.com>
To: =?UTF-8?Q?Johannes_Schl=C3=BCter?= <johannes@php.net>
Cc: "Olivier B." <php-dev.list@daevel.fr>, internals@lists.php.net
Content-Type: multipart/alternative; boundary=00032555a0cad3c8e00482659409
Subject: Re: [PHP-DEV] [PATCH] Raise warning first on "Maximum execution time 
	exceeded"
From: tyra3l@gmail.com (Ferenc Kovacs)

--00032555a0cad3c8e00482659409
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2010/3/22 Johannes Schl=C3=BCter <johannes@php.net>

> 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.
>
> Then why is this snippet working:

<?php
error_reporting(E_ALL);
ini_set('display_errors', 1);

register_shutdown_function(
function (){
echo 111;
}
);

if(ob_get_level()){
ob_end_flush();
}
echo 123;
flush();
$obj->func();
echo 456;

script execution can continue on fatal error.
you can use the register_shutdown_function, or the ob_start function
callback param to continue the execution after an uncatchable fatal error.
I think either this kind of errors should be catchable(except the errors in
the engine itself, not in the userland) or the above mentioned two method
shouldn't be working.

Tyrael

> johannes
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--00032555a0cad3c8e00482659409--