Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:9063 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 89437 invoked by uid 1010); 12 Apr 2004 15:06:05 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 89388 invoked from network); 12 Apr 2004 15:06:05 -0000 Received: from unknown (HELO longsword.omniti.com) (66.80.117.3) by pb1.pair.com with SMTP; 12 Apr 2004 15:06:05 -0000 Received: from [66.80.117.2] (helo=[10.80.116.129]) by longsword.omniti.com with asmtp (TLSv1:RC4-SHA:128) (Exim 4.14) id 1BD30f-0004zu-I8; Mon, 12 Apr 2004 11:06:05 -0400 In-Reply-To: References: <1081740243.14476.11.camel@coogle.localdomain> <5.1.0.14.2.20040412134325.039c7758@127.0.0.1> <200404120855.02983.ilia@prohost.org> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-ID: <25E0CA90-8C93-11D8-8792-000393B2B3C0@omniti.com> Content-Transfer-Encoding: 7bit Cc: Ilia Alshanetsky , Andi Gutmans , internals@lists.php.net Date: Mon, 12 Apr 2004 11:07:43 -0400 To: Adam Maccabee Trachtenberg X-Mailer: Apple Mail (2.613) Subject: Re: [PHP-DEV] Exceptions and Errors From: george@omniti.com (George Schlossnagle) On Apr 12, 2004, at 10:58 AM, Adam Maccabee Trachtenberg wrote: > On Mon, 12 Apr 2004, Ilia Alshanetsky wrote: > >> There is 1 problem with this approach. Currently an uncaught >> exceptions >> results in a fatal error (E_ERROR) meaning that if a particular >> method throws >> an exceptions it MUST be caught otherwise the script will terminate. >> Having >> to wrap some methods inside exceptions can be extremely frustrating >> since you >> may want to allow those methods to fail. > > Yes. This sucks. Maybe PHP should only issue exceptions for problems > of E_WARNING severity. An exception is an "Exceptional Event." If you > have an E_NOTICE or E_STRICT then that's an informational event, not a > exceptional one. I'm fine with this, but it's really just a documentation problem, right? Your method can still fail, you just need to try/catch around it. try { $obj->bornToFail(); } catch(Exception $e){} Uglier than just swallowing a warning for sure, but still just a doc problem. > Either that or uncaught exceptions should be E_WARNINGs instead of > E_ERRORs. (I don't want to introduce Java's checked versus unchecked > exception concept.) -1. George