On Mon, 12 Apr 2004, Ilia Alshanetsky wrote:
> 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.
Well, like I said, I'm against exceptions on E_NOTICE/E_STRICT. I
think there's some agreement on this point. Well, you, me, George, and
Derick. I add Derick because he's always against exceptions. :)
As to E_WARNINGs, what to do? Sometimes they can be safely ignored,
but it takes an experienced programmer to know those cases.
> > 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.
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);
}
I think only two sets of programmers do this. Unfortunately, they're
at the spectrums. Newbies and gurus. Newbies because they don't know
any better and gurus because they know exactly what's going to happen.
I'm trying to get newbies to move into the middle range and I'm
ignoring the top 1% of developers. :)
> > 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.
Right. Sorry about that. I had played around with trying to get SQLite to
throw exceptions and had placed the lastError() as the exception code.
> 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?
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.
I am willing to concede that SQL parse errors aren't the best example
here, but that doesn't mean extensions should never throw exceptions.
-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
