Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:9049 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 16020 invoked by uid 1010); 12 Apr 2004 05:27:50 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 15957 invoked from network); 12 Apr 2004 05:27:49 -0000 Received: from unknown (HELO miranda.org) (209.58.150.153) by pb1.pair.com with SMTP; 12 Apr 2004 05:27:49 -0000 Received: (qmail 32330 invoked by uid 546); 12 Apr 2004 05:27:49 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 12 Apr 2004 05:27:49 -0000 Date: Mon, 12 Apr 2004 01:27:49 -0400 (EDT) X-X-Sender: adam@miranda.org To: John Coggeshall cc: PHP Internals In-Reply-To: <1081740243.14476.11.camel@coogle.localdomain> Message-ID: References: <1081740243.14476.11.camel@coogle.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [PHP-DEV] Exceptions and Errors From: adam@trachtenberg.com (Adam Maccabee Trachtenberg) On Sun, 11 Apr 2004, John Coggeshall wrote: > As a matter of consistency, I would like to suggest that for those > extensions which have a OO/procedural syntax that the non-fatal errors > generated by those extensions be thrown as Exceptions when called from > an OO syntax. I have already committed such a change to Tidy, and I > can't see any serious reason why such a change can't be implemented for > internal classes. > > Feedback welcome. I wholeheartedly support this. I've been trying to document exception handling this week and it's extremely frustrating: 1) None (almost none?) of the internal classes use exceptions. This makes it difficult (if not impossible) to explain how to use exceptions because you cannot show a meaningful example. 2) Point #1 is a lie because internal classes throw exceptions when there's an error in the constructor. This is leads to wacky code: try { $db = new SQLiteDatabase('foo.db'); if ($db->query($sql)) { // fetch rows } else { // handle error } } catch { // handle exception } It's really crazy to need to mix both types of error handling within the same block of code. 3) Because internal classes don't use exceptions, I have no idea how anyone can meaningfully use exceptions in their code. Even if all userspace errors throw exceptions, people will miss lots of other errors (i.e the ones from internal classes) unless they explicitly check for them themselves and manually throw exceptions. Needing to turn errors into exceptions, however, seems to completely defeat one of the primary points of exception handling, which is separating core programming logic from error handling. I wish I had to foresight to realize this earlier, but it didn't emerge until I began to use PHP 5 in a more comprehensive way. -adam -- adam@trachtenberg.com author of o'reilly's php cookbook avoid the holiday rush, buy your copy today!