Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:25295
Return-Path: <helly@php.net>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 62558 invoked by uid 1010); 10 Aug 2006 17:52:44 -0000
Delivered-To: ezmlm-scan-internals@lists.php.net
Delivered-To: ezmlm-internals@lists.php.net
Received: (qmail 62543 invoked from network); 10 Aug 2006 17:52:44 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 10 Aug 2006 17:52:44 -0000
X-PHP-List-Original-Sender: helly@php.net
X-Host-Fingerprint: 81.169.182.136 ajaxatwork.net Linux 2.4/2.6
Received: from ([81.169.182.136:43852] helo=strato.aixcept.de)
	by pb1.pair.com (ecelerity 2.1.1.3 r(11751M)) with ESMTP
	id 0D/23-04634-ABD6BD44 for <internals@lists.php.net>; Thu, 10 Aug 2006 13:32:43 -0400
Received: from [192.168.1.3] (dslb-084-063-060-090.pools.arcor-ip.net [84.63.60.90])
	(using TLSv1 with cipher AES256-SHA (256/256 bits))
	(No client certificate requested)
	by strato.aixcept.de (Postfix) with ESMTP id 6C05C35C1F0;
	Thu, 10 Aug 2006 19:32:39 +0200 (CEST)
Date: Thu, 10 Aug 2006 19:32:49 +0200
Reply-To: Marcus Boerger <helly@php.net>
X-Priority: 3 (Normal)
Message-ID: <1216764972.20060810193249@marcus-boerger.de>
To: Michael Walter <michael.walter@gmail.com>
Cc: internals@lists.php.net
In-Reply-To: <877e9a170608100302n6407821dw5e55187332b74f4f@mail.gmail.com>
References: <877e9a170608100302n6407821dw5e55187332b74f4f@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Fatal errors
From: helly@php.net (Marcus Boerger)

Hello Michael,

  this is the expected behavior. But we migth as well simply remove all
those modifiers. That would be much better then providing them in a
senseless manner.

regards
marcus

Thursday, August 10, 2006, 12:02:09 PM, you wrote:

> Hi,

> right now, PHP triggers fatal errors e.g. when accessing private
> members or calling nonexistant functions. Since this is problematic
> for obvious reasons, what technical reasons are there for that
> behavior, and is there a chance that this behaviour will change in a
> future release?

> Regards,
> Michael




Best regards,
 Marcus