On Sun, Dec 8, 2013 at 9:33 AM, Zeev Suraski <zeev@zend.com> wrote:
> On Sun, Dec 8, 2013 at 4:18 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:>>>> Hi Zeev!>>>> I think this is a misunderstanding... I'm not suggesting to simply let the>> engine continue after an E_ERROR - as you pointed out, that would likely>> just crash it a few lines further down.>>>> This RFC is mainly a policy RFC: The goal is to allow the use of>> exceptions in the engine and to allow changing existing fatal errors to>> exceptions. The change from fatal errors to exceptions needs to happen>> manually, by adjusting the surrounding code to support continued execution>> (usually that means freeing resources + returning). A lot of fatal errors>> are easy to change, others are very hard or impossible. Changing fatal>> errors to exceptions rather than recoverable errors is both more useful to>> the end user and technically easier (as recoverable errors need to continue>> execution in the same codepath, which is often a lot harder to implement>> and find appropriate semantics for), which is why I'm suggesting this>> particular course of action.>>>> So, basically what I'm suggest is what you say in the last paragraph, just>> going directly to exceptions rather than converting to E_RECOVERABLE_ERROR>> :)>>>> Hope this is a bit clearer.>>>> 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.
Or I missed your point. :)