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.
If a user has written code expecting it to work in PHP 4 and PHP 5 with a registered error handler, it has to be completely rewritten. Exceptions, by nature, can not be caught at the global level and then modified, they are local. Of course, you could just surround your global code with a try {} catch {} but that is just about the worst hack I can imagine.
Unless there is a way to "resume" execution after the point of the error (i.e. exactly how the current error handling works), exceptions will only make things more exasperating. If I have to surround every single method call with try {} catch {}, that = a bad design decision.
- say byebye to readability
- what if an extension upgrades and throws a new, more specific kind of exception? instant code breakage, unless the catch-all is not paranoid
- EVERY try {} catch {} will need a catch-all, unless you're willing to risk total breakage later.
- error handling is suddenly forced to be directly integrated with program logic, and isn't that the opposite of exception handling's goals?
Greg
P.S.
This is what I mean by a "resume" statement:
function blah()
{
$a = $someobject->throwsexception();
$nextstatement = 'works?';
}...
try {
blah();
} catch (Exception $e) {
log_exception($e);
if (thingsareok()) {
resume; // execution starts at "$nextstatement = 'works?';"
}
}Without the ability to resume, we are forced to do
function blah()
{
try {
$a = $someobject->throwsexception();
} catch (Exception $e) {
$ok = pass_to_global_exception_handler_and_logger($e);
if (!$ok) {
throw ($e);
}
}
$nextstatement = 'ack';
}for even the most minor of error conditions
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
