Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:59347 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 64559 invoked from network); 4 Apr 2012 02:02:58 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Apr 2012 02:02:58 -0000 Authentication-Results: pb1.pair.com header.from=alan@akbkhome.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=alan@akbkhome.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain akbkhome.com designates 202.81.246.113 as permitted sender) X-PHP-List-Original-Sender: alan@akbkhome.com X-Host-Fingerprint: 202.81.246.113 akbkhome.com Received: from [202.81.246.113] ([202.81.246.113:35653] helo=akbkhome.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 5A/78-06658-1DBAB7F4 for ; Tue, 03 Apr 2012 22:02:58 -0400 Received: from wideboyhd.local ([192.168.0.28]) by akbkhome.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Mailfort v1.2) (envelope-from ) id 1SFFYk-0001jI-4X for internals@lists.php.net; Wed, 04 Apr 2012 10:02:54 +0800 Message-ID: <4F7BABC8.7040904@akbkhome.com> Date: Wed, 04 Apr 2012 10:02:48 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: internals@lists.php.net Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-mailfort-sig: 7c5581afd0583ec2f75d1e52d6ddcc0e Subject: Catchable - marking methods just like static? From: alan@akbkhome.com (Alan Knowles) I just saw Daniel changing some of the PEAR classes to use Exceptions, and it's pretty clear that this could cause havoc with the end users. The problem being that there is no 'soft' landing for the migration process. Users switching code from return style error handling to exceptions are not given any hints about what would be affected, and what may need fixing. This is mainly due to the fact that Exceptions can occur anywhere inside of multiple nested function calls, and failure to catch them is frequently due to missing the fact that a dependent library of function call could raise an exception. So in looking at how this could be addressed, I thought I'd throw this idea out there and see how it bounced.. PHP enforces rules like $this can not be used in a method marked 'static'. So why not flag methods (and internal functions) with a flag that indicates they can throw things. Since PHP is not a compiled language we can not pick up 'all' of the potential scenarios, but even if E_NOTICE's pick up 80% it would make code considerably more maintainable. So this is the rough outline.. Existing code that throws exception 1: function throwSomething() { 2: ... 3: throw new Exception 4: } Would produce Compile-time warning: "E_NOTICE: throw used inside non-catchable function on line 3" The remove the warning: 1: catchable function throwSomething() { 2: ... 3: throw new Exception 4: } Calling a function 1: function callThrow() 2: { 3: $this->throwSomething(); 4: } Would produce Run-time warning: "E_NOTICE catchable method called inside non-catchable function or try/catch on line 3" Fix: either wrap the call in try/catch or make the function catchable. Anyway... flame away ;) Regards Alan