Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:9062
Return-Path: <adam@trachtenberg.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 63452 invoked by uid 1010); 12 Apr 2004 14:58:03 -0000
Delivered-To: ezmlm-scan-internals@lists.php.net
Delivered-To: ezmlm-internals@lists.php.net
Received: (qmail 63415 invoked from network); 12 Apr 2004 14:58:03 -0000
Received: from unknown (HELO miranda.org) (209.58.150.153)
  by pb1.pair.com with SMTP; 12 Apr 2004 14:58:03 -0000
Received: (qmail 11312 invoked by uid 546); 12 Apr 2004 14:58:03 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
  by localhost with SMTP; 12 Apr 2004 14:58:03 -0000
Date: Mon, 12 Apr 2004 10:58:03 -0400 (EDT)
X-X-Sender: adam@miranda.org
To: Ilia Alshanetsky <ilia@prohost.org>
cc: internals@lists.php.net, Andi Gutmans <andi@zend.com>
In-Reply-To: <200404120855.02983.ilia@prohost.org>
Message-ID: <Pine.LNX.4.58.0404121039220.1153@miranda.org>
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
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: [PHP-DEV] Exceptions and Errors
From: adam@trachtenberg.com (Adam Maccabee Trachtenberg)

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.

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.)

> For example the query method in SQLite can safely be allowed to fail
> in certain instances. In other instances when you care about
> failures there may be a need to implement custom handlers depending
> on the nature of the error. For example if a query fails due to a
> uniqness constrait, an UPDATE query would be ran while in all other
> instances an error would be logged etc...

Still, you shouldn't be ignoring E_WARNINGs unless you have a good
reason. 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. :)

Handling UNIQUEness queries is exactly the type of problem you're
going to need to trap. For example:

try {
  $db = new SQLiteDatabase('foo.db');
  $db->query('INSERT...');
} catch (SQLiteException $e) {
  if ($e->getCode() == 19) {
    // UNIQUEness violation
    $db->query('UPDATE...');
  } else {
    // log error
    error_log($e->getMessage() . ': ' . $e->getCode());
  }
}

-adam

-- 
adam@trachtenberg.com
author of o'reilly's php cookbook
avoid the holiday rush, buy your copy today!