Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77795
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CA+kxMuROMzNDn0ivobDXj7BC4SQXzkW8dCLQxpH8r75tP2x0eA@mail.gmail.com>
References: <CAF+90c-7w1fLqmffYvPRhmtt8rzESEpSmW8vfMD-YfLt1mG_8w@mail.gmail.com>
	<543320AB.4070606@sugarcrm.com>
	<CA+kxMuROMzNDn0ivobDXj7BC4SQXzkW8dCLQxpH8r75tP2x0eA@mail.gmail.com>
Date: Tue, 7 Oct 2014 11:32:05 +0200
Message-ID: <CAH-PCH6Z7VbVz6Js26cHKLkUgF2Z6sQhq-MOSj=UqUf49=+vug@mail.gmail.com>
To: Dan Ackroyd <danack@basereality.com>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, Nikita Popov <nikita.ppv@gmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c1c9c856bda10504d1df86
Subject: Re: [PHP-DEV] [RFC] Exceptions in the engine
From: tyra3l@gmail.com (Ferenc Kovacs)

--001a11c1c9c856bda10504d1df86
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Oct 7, 2014 at 10:55 AM, Dan Ackroyd <danack@basereality.com> wrote=
:

> Stas wrote:
>
> > The only issue I think we need to discuss is catch(Exception $e). Now i=
t
> > 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.
> }
>


we discussed this before on the mailing list, the problem would be that
currently the fatal errors will stop the execution and even recoverable
fatals for most people (when they don't have a global error handler defined
to handle it) and theoretically it is possible that some code exists out
there with Pokemon Exception Handling (
http://c2.com/cgi/wiki?PokemonExceptionHandling) where the code would
continue the execution and probably does some logically faulty operation
which previously was only prevented by the fatal error stopping the code.
this indeed assumes that the user already follow bad coding practices(Catch
them all) and code with (potential) fatal errors so there were a
disagreement if we could afford this BC or not.
Personally I think that it would be fine for a major version.

>
>
--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--001a11c1c9c856bda10504d1df86--