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. 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? About the long error message - I usually wouldn't recommend that but maybe here is a good place for an ini setting, saying if we really want to display the stack trace for uncaught exceptions? In many production systems, wasting time to collect and then print the backtrace may not be needed, and one-point message is enough. Many tools already have such option (xdebug included) so maybe if we move to exceptions core may have something like that too? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
