Hello Zeev, Friday, June 20, 2003, 1:52:55 AM, you wrote:
ZS> At 23:07 19/06/2003, George Schlossnagle wrote: >>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. ZS> Except errors today have a 'contract' where PHP doesn't have to be in a ZS> stable situation, because we know for sure that it's not going to continue ZS> executing. This whole errors-as-exceptions would have been useful ZS> particularly for warnings (e.g., handle failed SQL operations, etc.) but ZS> it's not possible without serious compatibility breaking side effects. Not ZS> to mention that the ability to handle fatal errors but not non-fatal errors ZS> using this method is awkward to begin with, and not very easy to explain ZS> (just think about how many people were unhappy with set_error_handler()'s ZS> inability to handle fatal errors, now think about a similar problem, only ZS> much worse, as it's almost impossible to give a simple reason as to why ZS> it's like this, other than downwards compatibility). As someone already pointed out there are only a few errors (less than 5 maybe) which leave php in an unrecoverable state. Also i think they should be changed because such a state should be shown by one of the "real errors". And i agree that no such error should be converted to an exception. To make it clear, the idea is to convert all messages not of the following types: E_ERROR E_CORE_ERROR E_COMPILE_ERROR E_USER_ERROR E_PARSE In other words i'd like E_WARNINGS to be converted, because that is the normal message generated from functions like database errors ... ZS> If we were to implement any sort of thing like that, and that's a big if, ZS> I'd concentrate on converting the OO-related fatal errors into their own ZS> type, and make them exceptions. While I strongly disprove of ZS> exception-oriented programming, other than allowing/encouraging people to ZS> 'abuse' the language, I don't see any other negative effects. If it's ZS> limited to the context of fatal OO errors, it'll most probably be used only ZS> by the people who are fairly clueful (albeit not clueful enough to know ZS> that exception-oriented programming is a bad thing :) ZS> All in all, I would definitely not see errors-as-exceptions as a ZS> pre-requisite for the beta. It's not an issue to be dealt with lightly, ZS> and we probably won't have time to finalize it in the next few days that we ZS> have left. Not a prerequsit.....but then we could have beta out months earlier ... i am talking about some language behavior modification, yes. Changes to language behavior we don't do before beta we don't do ever...anyway the only reason for the pace towards beta now. Noone should insist on using exceptions - they are exceptions - and as such they are very helpfull in handling exceptional errors or other unexpected program states. They also allow a means of requirements engineering and such. And as stated earlier - at least for constructors there is no other way than failing with exceptions and catching them. >From my perspective we are again at a point where we can do a stupid oo implementation which suffers from the holy bc complaints or do it correct. Maybe the solution is to do it correct but configurable by ini setting. This way we can do both keep bc where needed and more sophisticated ways for new apps. [p.s.: And don't tell me what to do or not to do with exceptions - i live with that in c++ everyday.... :-) ...or better :-(( ] -- Best regards, Marcus mailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
