On Tue, Oct 7, 2014 at 1:07 AM, Stas Malyshev <smalys...@sugarcrm.com> wrote:
> Hi! > > > As such I'm re-proposing this RFC for inclusion in PHP 7: > > > > https://wiki.php.net/rfc/engine_exceptions_for_php7 > > > > The RFC text is essentially the same as previously, with the primary > > difference being that parse errors are now converted to exceptions as > well. > > This was previously not possible due to limitations in the compiler > design. > > I like this. Fatal errors and warnings were for a long time in different > leagues, and the need to handle them better produced E_RECOVERABLE_ERROR > which is a weird creature - like exception but not quite. I think PHP 7 > is a good time to move to exceptions for real errors (as opposed to > informational messages like E_WARNING). > > The only issue I think we need to discuss is catch(Exception $e). Now it > would catch much more than before, if we do no changes. Should we allow > it or should be have hierarchy that separates user exceptions and engine > exceptions, and have catch(Exception) catch only the former. > There is precedent in other languages for having exceptions that are not usually caught. Java has a Throwable interface, which is implemented by Exceptions and Errors, where the latter are usually not supposed to be caught. Python has a BaseException, which is extended by Exception and SystemExit, GeneratorExit and KeyboardInterrupt, where the latter three are not usually supposed to be caught. I think that the decision whether or not we wish to introduce something like this mainly depends on how we intend these EngineExceptions to be used. If they are only supposed to be caught by top-level code to enable graceful error handling (in particular for long running code) then it probably makes sense to keep them outside the main exception hierarchy. If on the other hand it's considered okay to catch them during normal program execution, they should be normal exceptions. > However, I see in the RFC it does not remove all the errors. I think we > need to strive for having all the non-core errors except for out of > memory and timeout be converted. Are there ones that are problematic to > convert or it is just the question of time/effort? > There are a number of E_ERRORs that we cannot feasibly convert to exceptions. I've analyzed this for the previous discussion and likely the numbers are still about right: http://markmail.org/message/gfdczr6zpgzynid4 So a conservative estimate is that we can turn 85% of the E_ERROR occurrences into exceptions. (This doesn't tell us anything about the percentage of actually thrown errors though.) And yes, it's also a question of time/effort. The hard part usually isn't converting to exceptions, but updating all the tests that fail because of it. I'd like to have good exception coverage by the time PHP 7 gets released, but would prefer to do the porting incrementally (these huge patches get stale very fast). Nikita
