php5 beta

Hello Zeev, Friday, June 20, 2003, 1:52:55 AM, you wrote: ZS> At 23:07 19/06/2003, George Schlossnagle wrote:

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 :-(( ]

"Zeev Suraski" <zeev@zend.com> wrote in message news:5.1.0.14.2.20030620024310.06189538@localhost...

we

fair enough. but in the absence of that solution, the one thing i would greatly appreciate is a modification to zend_parse_parameters (a new parameter ?) to either : 1.) return the text of error messages without raising a warning itself. that way i can raise an IllegalArgumentException or somesuch myself 2.) create and raise an IllegalArgumentException (or just Exception) of its own. right now my code is written assuming something like the second would happen (with the new parameter). so barring that, im in the position of either 1. using only PHP errors (not nice for an OOP exception, especially in constructors) 2. having both an exception and regular error raised (since this is the default of zend_parse_parameters) <code> if (FAILURE == zend_parse_parameters(ZEND_NUM_ARGS()TSRMLS_CC, "l", &length)) { RAISE_AN_ILLEGAL_ARGUMENT_EXCEPTION("Bad value for length parameter.") return; } </code> 3. reverting to the old parameter parsing API to handle things myself 4. do like Marcus and implement a boatload of exception-rainsing-parameter-parsing stuff myself and hope it gets into the engine <g> l0t3k

At 03:21 20/06/2003, Marcus Börger wrote:

In other words, different people have very different views about what this should look like, very contradictory ideas. Your idea of 'do it right' vision involves forcing people to use exceptions (otherwise, their code will not cooperate nicely with other people's code or in certain setups). That's a clear 'do it wrong' vision in my book, which brings us the tremendous amounts of fun on these mailing lists :) Zeev