On Sat, 2004-02-14 at 11:38, Zeev Suraski wrote:
> >>My experience is a bit of the opposite, and the truth is somewhere in the
> >>middle I guess. But anyway, if you want to error out, why not just do
> >>that? Why go through the mess of coming up with an exception that will
> >>propagate through God knows how many checks and hopefully won't be caught?
It is my understanding that exceptions exist to prevent you from having
to "just error out."
> >Because you want it to be catchable by someone who is looking for it.
>
> Are you talking about some plugin system where you want to send exceptions
> from lower layers to upper layers, bypassing the user-code in the
> middle? Otherwise, I don't see why you'd ever want to do that, and that's
> a fairly esoteric case. If you just want to be able to clean up nicely at
> the extension level or something like that, instead of using
> set_exception_handler() to identify this exception and do something
> special, why not use set_error_handler()?
In a rich object based application there could be multiple levels within
the application itself. One example I can think of that relates to
conditionally handling exceptions uses data access (pseudo code):
class NoDataException implements Throwable;
class DatabaseException extends Exception implements Throwable;
class MysqlException extends DatabaseException implements Throwable;
function getData($table_name, $key) throws
NoDataException, DatabaseException {
$result = mysqlGetData($table_name, $key);
if ($result == NULL) { // A MySQL error occured
throw new MysqlException(mysql_get_error());
return $result;
} else if $result == 0) { // There were no records
throw new NoDataException($table_name);
return $result;
} else {
return $result;
}
}
function doStuff() {
try {
$data = getData('table', 2);
} catch (NoDataException e) {
// Oops, no data. Ask for a different key before proceeding.
}
}
This uses exceptions to propagate an application error that the
application should gracefully handle. This type of error should be
caught by the application and not passed up. If it is passed up it is
effectively useless outside of its layer. It would be more appropriate
for this to be treated as an un-handled exception (bad programming) than
for it to be caught in some mass exception handler and its error dumped
to the screen. The MysqlException is a system application and could
result in more drastic action. For example if GUI information is stored
in the database, continuing with the application may not be possible.
If it is possible to continue (backup database, etc.) then the exception
can be handled. Otherwise it should be handled gracefully later. In
other words it may be useful for some exceptions to be handled by a
generic exception handler up the propagation chain, however some
exceptions should pass un-handled to php. Implementing
set_error_handler() in getData or doStuff is sub-optimal because higher
layers may be able to (or need to) handle the exception. I think a base
exception class as well as a Throwable interface would be a good idea.
However, I do not think all exceptions should be required to inherit
Exception, only implement Throwable. Another example is using
exceptions to throw validation errors.
Regards,
Adam
--
Adam Bregenzer
[EMAIL PROTECTED]
http://adam.bregenzer.net/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
