Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:9082 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 1457 invoked by uid 1010); 12 Apr 2004 18:14:46 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 1384 invoked from network); 12 Apr 2004 18:14:45 -0000 Received: from unknown (HELO spawn.leetspeak.org) (217.28.101.185) by pb1.pair.com with SMTP; 12 Apr 2004 18:14:45 -0000 Received: (qmail 14300 invoked from network); 12 Apr 2004 20:14:55 +0200 Received: from unknown (HELO mail.leetspeak.org) (127.0.0.1) by localhost with SMTP; 12 Apr 2004 20:14:55 +0200 Received: from 217.224.60.178 (SquirrelMail authenticated user cm) by mail.leetspeak.org with HTTP; Mon, 12 Apr 2004 20:14:55 +0200 (CEST) Message-ID: <33080.217.224.60.178.1081793695.squirrel@mail.leetspeak.org> In-Reply-To: <25E0CA90-8C93-11D8-8792-000393B2B3C0@omniti.com> References: <1081740243.14476.11.camel@coogle.localdomain> <5.1.0.14.2.20040412134325.039c7758@127.0.0.1> <200404120855.02983.ilia@prohost.org> <25E0CA90-8C93-11D8-8792-000393B2B3C0@omniti.com> Date: Mon, 12 Apr 2004 20:14:55 +0200 (CEST) To: internals@lists.php.net User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Subject: Re: [PHP-DEV] Exceptions and Errors From: cm@leetspeak.org > > 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. Might there be a possibility that an exception inside a "@ context" could be ignored, too (that might also work with active custom error handlers, I guess)? Cheers, Michael