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
--
[EMAIL PROTECTED]
author of o'reilly's php cookbook
avoid the holiday rush, buy your copy today!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
