Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:9065 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 1843 invoked by uid 1010); 12 Apr 2004 15:09:34 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 1813 invoked from network); 12 Apr 2004 15:09:33 -0000 Received: from unknown (HELO asuka.nerv) (24.100.195.79) by pb1.pair.com with SMTP; 12 Apr 2004 15:09:33 -0000 Received: (qmail 28217 invoked from network); 12 Apr 2004 15:09:33 -0000 Received: from rei.nerv (HELO dummy.com) (rei@192.168.1.1) by asuka.nerv with SMTP; 12 Apr 2004 15:09:33 -0000 Reply-To: ilia@prohost.org Organization: Prohost.org To: internals@lists.php.net Date: Mon, 12 Apr 2004 11:09:44 -0400 User-Agent: KMail/1.6.1 References: <1081740243.14476.11.camel@coogle.localdomain> <200404120855.02983.ilia@prohost.org> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-ID: <200404121109.44904.ilia@prohost.org> Subject: Re: [PHP-DEV] Exceptions and Errors From: ilia@prohost.org (Ilia Alshanetsky) On April 12, 2004 10:58 am, Adam Maccabee Trachtenberg wrote: > Still, you shouldn't be ignoring E_WARNINGs unless you have a good > reason. There are plenty of situations where E_WARNING can be safely ignored. And even more situations where E_NOTICE/E_STRICT can be ignored. > Your code cannot correctly retrieve those rows from the > database when you've ignored the error telling you that there was a > problem connecting to the database. :) You may not want to retrieve the rows in the 1st place. > Handling UNIQUEness queries is exactly the type of problem you're > going to need to trap. For example: Your example is not entirely correct. You'd first need to use $db->lastError() to the error code, $e->getCode() will return something else all together. However the bottom line is that now your exception handling mechanism is far more complex then it should/could be. If your block has a query() method with a query that can fail you'd need to add special conditions to handle it in the end you end up with an overly complex handling mechanism. If you start putting an try {} catch {} block around every individual query method as an alternative, then you kill the whole point of exceptions, no? Ilia