Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77794
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain basereality.com from 209.85.212.182 cause and error)
MIME-Version: 1.0
In-Reply-To: <543320AB.4070606@sugarcrm.com>
References: <CAF+90c-7w1fLqmffYvPRhmtt8rzESEpSmW8vfMD-YfLt1mG_8w@mail.gmail.com>
	<543320AB.4070606@sugarcrm.com>
Date: Tue, 7 Oct 2014 09:55:17 +0100
Message-ID: <CA+kxMuROMzNDn0ivobDXj7BC4SQXzkW8dCLQxpH8r75tP2x0eA@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] Exceptions in the engine
From: danack@basereality.com (Dan Ackroyd)

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 <smalyshev@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
>