ZS>I don't see any advantage to that at all. Either exceptions inherit from ZS>exception or not, there's no reason to complicate things with a new ZS>interface. We don't have different kinds of throwables, so doing that ZS>appears to be pure mental overhead. I also failed to understand why ZS>modules would not want to inherit the basic Exception class. If the ZS>exception is not supposed to be caught in user space, why throw it? If you ZS>can recover, recover now, or bail out (or both). IMHO, we can do things in two ways: 1) We can restrict 2) We can recomend (and not restrict) and know that it depends on the developer
ZS>Marcus - I don't see the problem having people write catch (Exception $foo) ZS>instead of catch ($foo). Our object orientation has become more strict ZS>than structured PHP already. Making exceptions more PHPish by introducing ZS>new terms and requirements appears to defeat the purpose. Ok. If we take option (2) there should be a public recomendation that all exceptions that we want to get caught (and don't want to abort the application/page) should inherit from Exception. Is that right ? Cristiano Duarte -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
