Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:62014 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 87613 invoked from network); 3 Aug 2012 16:11:18 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Aug 2012 16:11:18 -0000 Authentication-Results: pb1.pair.com smtp.mail=ajf@ajf.me; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=ajf@ajf.me; sender-id=pass Received-SPF: pass (pb1.pair.com: domain ajf.me designates 64.22.89.133 as permitted sender) X-PHP-List-Original-Sender: ajf@ajf.me X-Host-Fingerprint: 64.22.89.133 oxmail.registrar-servers.com Linux 2.6 Received: from [64.22.89.133] ([64.22.89.133:37200] helo=oxmail.registrar-servers.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E3/AD-09659-528FB105 for ; Fri, 03 Aug 2012 12:11:17 -0400 Received: from [192.168.0.200] (5ad4bfa0.bb.sky.com [90.212.191.160]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oxmail.registrar-servers.com (Postfix) with ESMTPSA id 75202C30008; Fri, 3 Aug 2012 12:11:13 -0400 (EDT) Message-ID: <501BF803.7070200@ajf.me> Date: Fri, 03 Aug 2012 17:10:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Ferenc Kovacs CC: Stan Vass , Leigh , internals@lists.php.net References: <3F2B7A4F937D4FA9A1CE88818CBCEB1D@pc> <501BF3B7.9020304@ajf.me> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090104060602020104030509" Subject: Re: [PHP-DEV] Why do disabled functions / classes generate a WARNING. From: ajf@ajf.me (Andrew Faulds) --------------090104060602020104030509 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 03/08/12 17:04, Ferenc Kovacs wrote: > > > Warnings are special, they aren't really errors as such. They > wouldn't become exceptions. > > Also, why should an erroring function return a value? > > > from > "My experience shows it's best to have an error handler convert all > errors to catchable exceptions, with some error types (like E_STRICT, > E_ERROR etc.) to become instant fatal errors (can't be caught)." > I think he is talking about turning everything(E_NOTICE, E_WARNING, > etc.) into exceptions except a few, which can't be catched (why should > E_STRICT be uncatchable?! ). Of course some can't be caught. The kind that can't are ones that can't be for obvious reasons. Runtime errors, for instance. > Which brings up the issues that I mentioned before. > Getting the return of an erroring function isn't such a big issue, but > turning everything into exceptions would prevent getting any return > value from any function/operation which triggers anything, I don't see how the return value is needed if it has errored. Warnings are different, but they wouldn't become exceptions. > > Personally I think that turning everything into exceptions is a bad > idea, and it would make stuff which possible currently impossible. Examples, please? I think making more things into exceptions, and hence catchable, makes more stuff possible (recovering from trying to use non-existent functions, for example) > On the other hand, I think that we have many E_ERROR which could be > turned into E_RECOVERABLE_ERROR. > Which in turn could be turned into Exception by an userland error > handler if the php userland developer wishes it. Why not just have them exceptions in the first place? > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu -- Andrew Faulds http://ajf.me/ --------------090104060602020104030509--