Stas wrote:
> 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.
It's not clear why would that be an issue - can you specify what the
problem would be?
Also, if we changed `catch(Exception $e)` to not catch all exceptions,
than we would need to have another way of specifying that a catch
block should catch all exceptions. Which would involve either making
\Exception extend another even 'baser' Exception, or a hack to the
syntax e.g. something like:
catch($e) {
// Catch without Exception type catches all exceptions
// and confuses people.
}
cheers
Dan
Ack
On 7 October 2014 00:07, 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.
>
> 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
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
