Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77793
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.75 as permitted sender)
Message-ID: <543320AB.4070606@sugarcrm.com>
Date: Mon, 06 Oct 2014 16:07:23 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: Nikita Popov <nikita.ppv@gmail.com>, 
 PHP internals <internals@lists.php.net>
References: <CAF+90c-7w1fLqmffYvPRhmtt8rzESEpSmW8vfMD-YfLt1mG_8w@mail.gmail.com>
In-Reply-To: <CAF+90c-7w1fLqmffYvPRhmtt8rzESEpSmW8vfMD-YfLt1mG_8w@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Exceptions in the engine
From: smalyshev@sugarcrm.com (Stas Malyshev)

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/