Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:9070 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 56829 invoked by uid 1010); 12 Apr 2004 16:10:16 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 56763 invoked from network); 12 Apr 2004 16:10:15 -0000 Received: from unknown (HELO asuka.nerv) (24.100.195.79) by pb1.pair.com with SMTP; 12 Apr 2004 16:10:15 -0000 Received: (qmail 28868 invoked from network); 12 Apr 2004 16:10:15 -0000 Received: from rei.nerv (HELO dummy.com) (rei@192.168.1.1) by asuka.nerv with SMTP; 12 Apr 2004 16:10:15 -0000 Reply-To: ilia@prohost.org Organization: Prohost.org To: PHP Internals Date: Mon, 12 Apr 2004 12:10:27 -0400 User-Agent: KMail/1.6.1 References: <1081740243.14476.11.camel@coogle.localdomain> <200404121109.44904.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: <200404121210.27012.ilia@prohost.org> Subject: Re: [PHP-DEV] Exceptions and Errors From: ilia@prohost.org (Ilia Alshanetsky) On April 12, 2004 11:42 am, Adam Maccabee Trachtenberg wrote: > As to E_WARNINGs, what to do? Sometimes they can be safely ignored, > but it takes an experienced programmer to know those cases. Perhaps, but if you limit the experienced programmer's options and/or make using more advanced capabilities of the language more difficult you will lose those programmers to other languages. Consequently these programmers are usually the ones responsible for large deployments of the language. > So you're saying you write code like: > > // Don't care if this prints anything: > $db = new SQLiteDatabase('foo.db'); > $r = $db->query($sql); > foreach ($r as $row) { > processRow($row); > } Almost ;-) $r = $db->query($sql) or sql_error_handler($sql, $db); It'll be the job of sql_error_handler() to determine what type of an error had occurred and what action to take if any. > FWIW, I just checked, and Java handles this dilemma in JDBC by *not* > throwing exceptions upon SQL warnings. They still throw SQLExceptions > for major DB errors. Well, that would mean that you'll never be certain what may throw an exceptions giving you a nasty mix of both that will confuse experienced and inexperienced developers alike. Ilia