Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:56629 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 74109 invoked from network); 25 Nov 2011 10:44:34 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Nov 2011 10:44:34 -0000 Authentication-Results: pb1.pair.com smtp.mail=tyra3l@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=tyra3l@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.170 as permitted sender) X-PHP-List-Original-Sender: tyra3l@gmail.com X-Host-Fingerprint: 209.85.216.170 mail-qy0-f170.google.com Received: from [209.85.216.170] ([209.85.216.170:43923] helo=mail-qy0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 9D/05-45850-1917FCE4 for ; Fri, 25 Nov 2011 05:44:33 -0500 Received: by qyk33 with SMTP id 33so2593935qyk.29 for ; Fri, 25 Nov 2011 02:44:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hJmRg5kwbdJ+t7NPui+eAnixYjD181v5hMXS8Wd8ikQ=; b=YPogp0tLHeBSt3si5X8d+BpstiqfeX6PuWYfReCEC7AIyaEcSyt6EoR2CYzuKN5/w2 4kXLz8e7B64JgLC9Kp0tSvpMNP7bAWYuDPnZHR3v/QGqDhqp9eV2zCIDkzpYlCESqKuk +UjP5iWbC6WwiISQSI1opDlbEcA2laxSmIx60= MIME-Version: 1.0 Received: by 10.229.101.93 with SMTP id b29mr3709452qco.110.1322217871024; Fri, 25 Nov 2011 02:44:31 -0800 (PST) Received: by 10.229.38.134 with HTTP; Fri, 25 Nov 2011 02:44:30 -0800 (PST) In-Reply-To: References: <4ECEC513.9040706@mohiva.com> <06acba1a1c53ac9527beb807787c92aa@mohiva.com> Date: Fri, 25 Nov 2011 11:44:30 +0100 Message-ID: To: Sebastian Krebs Cc: internals@lists.php.net Content-Type: multipart/alternative; boundary=00163649923784a28004b28cd6cc Subject: Re: [PHP-DEV] Re: [RFC] Autoloader Error Handling From: tyra3l@gmail.com (Ferenc Kovacs) --00163649923784a28004b28cd6cc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Nov 25, 2011 at 11:21 AM, Sebastian Krebs wrote: > 2011/11/25 Ferenc Kovacs > > > The problem with fatal, that you have no way (by the standard means, bu= t > > you can somehow manage it through the usage of output buffers or > > register_shutdown_function, but thats ugly, and can change in the futur= e) > > to intercept and gracefully terminate your application, which is an oft= en > > needed feature. > > AFAIK E_FATAL should be only used where the engine is left in an unstab= le > > state, which isn't really true here. > > > > Trying to interact with a non-existing class is not an unstable state? > "where the __engine__ is left in an unstable state" trying to interact with a non-existing class could push the __application__ in an unstable state, but changing E_ERROR to E_RECOVERABLE_ERROR would give a chance for those developers/applications to gracefully terminate. > there are two situations: > > 1. The application is broken, thus the FATAL is appropriate > so should we change all instance of E_NOTICE, E_WARNING and E_STRICT to E_ERROR? usually those also mean that the code is broken... > 2. The application tries to work with dynamic class names. If it doesn't > use class_exists() before, its broken and FATAL is appropriate > same here. I agree that trying to load an non-existing class is a bug, but E_ERROR is not a punishment for buggy code, it is a safety measure, when there is no safe way to give back the control to the application, because the engine for that request is beyond repair. --=20 Ferenc Kov=C3=A1cs @Tyr43l - http://tyrael.hu --00163649923784a28004b28cd6cc--