Re: [VOTE] Allowing use of exceptions in the engine

On Mon, Dec 9, 2013 at 10:58 AM, Zeev Suraski <zeev@zend.com> wrote: >> > OK, got you. Not using exceptions in the engine was also a design >> > decision (so that we don't force OO concepts on non-OO people) - need >> > to think if it still makes sense and get back to the vote. >> > >> > Thanks! >> > >> > Zeev >> >> I think it is fair to say there is a big difference between "forcing OO > concepts >> on non-OO people" and which is what is being proposed >> here: "this is an object which you can use if you'd like to find out > what is >> happening with this exception." >> >> No PHP developer is going to get away with not using any objects ever >> regardless of their preferred design approach, so offering them > exception >> objects is not going to frighten anyone off. > > While I disagree that all PHP developers would have to use objects (you > can live a full healthy procedural life in PHP) - regardless, exceptions > and their jargon is a much more advanced OO concept than just using plain > objects. Throwing, catching, propagation rules, try/catch/finally - those > all come hand in hand with exceptions. We've made a conscious decision > not to force this on users back when we introduced exceptions, and keep > the engine use errors only (which can be converted to exceptions easily > enough using error handlers). > > Note that I think that this part is debatable - I'm a lot more worried on > the feedback Dmitry provided earlier today (although I admit I'm not crazy > of just keeping things the way they, and letting those who are interested > in exceptions convert errors to exceptions on their own). > > Zeev Right, you can absolutely live a full and healthy life in PHP using entirely procedural code (things like the dual interfaces for MySQLi ensure that) but I really really do not see "here is an object, try/catch/finally or EngineException" as "forcing OO concepts on non-OO people" because it isn't. The user does not need to worry about propogation rules unless they start writing their own exceptions and try/catch/finally is not inherently OOP. Even if it was the average procedural user is just going to see the difference of "Fatal Error you code is screwed" changing to "Uncaught Engine Exception your code is screwed" if they don't want to bother catching anything, which they wouldn't if they didnt want to use try/catch... so the whole thing is a bit of a non-argument. I know it is not your main concern, but I really don't want this argument being used as one against this RFC in general.