Marcus Börger wrote: > If all exception objects must be instances of classes derived from > exception or that class itself..well..why then specify exception.
That's why proposed the following a *long* time ago:
* Introduce
interface Throwable {}
as built-in interface.
* Allow only classes implementing the Throwable interface to be throw()n.
* Provide the current Exception class (implementing avove interface) as a standard exception class.
I don't see any advantage to that at all. Either exceptions inherit from exception or not, there's no reason to complicate things with a new interface. We don't have different kinds of throwables, so doing that appears to be pure mental overhead. I also failed to understand why modules would not want to inherit the basic Exception class. If the exception is not supposed to be caught in user space, why throw it? If you can recover, recover now, or bail out (or both).
Marcus - I don't see the problem having people write catch (Exception $foo) instead of catch ($foo). Our object orientation has become more strict than structured PHP already. Making exceptions more PHPish by introducing new terms and requirements appears to defeat the purpose.
Zeev
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
