Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:25284 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 21440 invoked by uid 1010); 10 Aug 2006 11:46:14 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 21418 invoked from network); 10 Aug 2006 11:46:14 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 10 Aug 2006 11:46:14 -0000 X-PHP-List-Original-Sender: derick@php.net X-Host-Fingerprint: 82.94.239.5 jdi.jdi-ict.nl Linux 2.5 (sometimes 2.4) (4) Received: from ([82.94.239.5:33206] helo=jdi.jdi-ict.nl) by pb1.pair.com (ecelerity 2.1.1.3 r(11751M)) with ESMTP id 23/E8-08715-C7C1BD44 for ; Thu, 10 Aug 2006 07:46:10 -0400 Received: from localhost (localhost [127.0.0.1]) by jdi.jdi-ict.nl (8.13.7/8.12.11) with ESMTP id k7ABjroK011973; Thu, 10 Aug 2006 13:45:53 +0200 Date: Thu, 10 Aug 2006 13:44:21 +0200 (CEST) X-X-Sender: derick@localhost To: Pierre cc: Michael Walter , Lukas Kahwe Smith , internals@lists.php.net In-Reply-To: Message-ID: References: <877e9a170608100302n6407821dw5e55187332b74f4f@mail.gmail.com> <44DB0DB5.6000707@php.net> <877e9a170608100354n239cd1f0q1f44bef9680ce91d@mail.gmail.com> X-Face: "L'&?Ah3MYF@FB4hU'XhNhLB]222(Lbr2Y@F:GE[OO;"F5p>qtFBl|yVVA&D{A(g3[C}mG:199P+5C'v.M/u@Z\![0b:Mv.[l6[uWl' MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [PHP-DEV] Re: Fatal errors From: derick@php.net (Derick Rethans) On Thu, 10 Aug 2006, Pierre wrote: > On 8/10/06, Michael Walter wrote: > > Yeah. It is problematic that the application has no chance of dealing > > with the errors itself (consider e.g. php-shell which has to go great > > lengths to prevent fatal errors from user code leading to php-shell's > > termination, and still fails at doing this in the general case). > > Why object should act differently than other php variables or > constants? Undefined constant, variable, index or offset do not raise > a fatal error. It should be the same for the object (constants, props, > visibility,...). He wasn't talking about *undefined variables* at all. The variable *is* defined as private and calling that is ofcourse not allowed. The second thing is that calling normal undefined functions throws a fatal error as well, and it should do that just like calling non existing methods on an object should throw a fatal error. regards, Derick