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

On Mon, Dec 9, 2013 at 5:22 PM, Zeev Suraski <zeev@zend.com> wrote: > For me it is an argument. Instead of being able to handle these errors in > the same way they handle all other errors, now they have to learn new > syntax and concepts. I see no reason to change the status quo, which > allows those who want exceptions to easily convert errors to thrown > exceptions, into a state where those who don't want to use exceptions are > forced to use them. Again, it's entirely fair that we disagree... > You can't convert fatal errors to exceptions using an error handler. That's why I'm targeting fatal errors here and not all errors in general. While I'm not a big fan of PHP's error system in general, it's easy enough to turn warnings or notices into exceptions via error handlers. But for fatal errors that's just not possible. To achieve what I want it would be enough to turn fatal errors into recoverable fatal errors, that would already allow the error handler approach. But that's a lot harder to do (and imho less usable) than directly using exceptions. Keeping the engine stable after an exceptions is relatively simple, the same can't be said about recoverable fatals. Regarding the "forcing OO concepts": As Philip pointed out, unless you already make use of try/catch a fatal error and an uncaught exception are about the same to the end user - actually, an uncaught exception is just a special fatal error. I could totally understand your concerns - if this discussion weren't about fatal errors. E.g. changing a warning to an exception would cause lots of issues. The @ operator would stop working and people would be forced to use try/catch. But for fatals @ never worked in the first place. You can't handle them right now. Changing them to exceptions adds the ability to handle them via try/catch, but of course you don't need to do them. You can let them bubble (and in most cases that's what you should do) and let them effectively act the same way as a fatal error currently does, just with a bit of a different message ;) Thanks, Nikita