My understanding of the proposal is that it is errors as exceptions, not warnings. errors are fatal in php4, so I don't see how it would change the behavior of any code block written for 4.
Except errors today have a 'contract' where PHP doesn't have to be in a stable situation, because we know for sure that it's not going to continue executing. This whole errors-as-exceptions would have been useful particularly for warnings (e.g., handle failed SQL operations, etc.) but it's not possible without serious compatibility breaking side effects. Not to mention that the ability to handle fatal errors but not non-fatal errors using this method is awkward to begin with, and not very easy to explain (just think about how many people were unhappy with set_error_handler()'s inability to handle fatal errors, now think about a similar problem, only much worse, as it's almost impossible to give a simple reason as to why it's like this, other than downwards compatibility).
If we were to implement any sort of thing like that, and that's a big if, I'd concentrate on converting the OO-related fatal errors into their own type, and make them exceptions. While I strongly disprove of exception-oriented programming, other than allowing/encouraging people to 'abuse' the language, I don't see any other negative effects. If it's limited to the context of fatal OO errors, it'll most probably be used only by the people who are fairly clueful (albeit not clueful enough to know that exception-oriented programming is a bad thing :)
All in all, I would definitely not see errors-as-exceptions as a pre-requisite for the beta. It's not an issue to be dealt with lightly, and we probably won't have time to finalize it in the next few days that we have left.
Zeev
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
