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
--
[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
