Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87810
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain adamharvey.name designates 209.85.217.171 as permitted sender)
MIME-Version: 1.0
Sender: adam@adamharvey.name
In-Reply-To: <55D490AB.7030507@telia.com>
References: <20150817123142.13418f26@csystems> <CANUQDCiCdzvyn2m4VCF8cL85H-VWPYMjOYBEHh=fwqLaPj4+zw@mail.gmail.com>
 <20150817131900.66906015@csystems> <alpine.DEB.2.20.1508171458420.3273@whisky.home.derickrethans.nl>
 <55D1EE8E.9030603@php.net> <CAPg3XxL7zAA-6Q3Eo--DqYZJ9DH+d--punuYj_ihR9OmR_L1pg@mail.gmail.com>
 <55D45278.5050005@telia.com> <CANUQDCjHEi=iLYL8mK=9xEy9C8MZ1Ciix9MGU0e8qM9x9qVTLw@mail.gmail.com>
 <55D479F1.5000408@telia.com> <CAObuZdswW_LJgA6L2hX5XNWJvGRExfrg9MYCo2PCeRQqy_jGcg@mail.gmail.com>
 <55D490AB.7030507@telia.com>
Date: Wed, 19 Aug 2015 11:15:17 -0700
Message-ID: <CADajX4BRcNmEHRsi3vNstXf7kUR=24YS5JhoZFR8g6DHuNwHOQ@mail.gmail.com>
To: =?UTF-8?Q?Bj=C3=B6rn_Larsson?= <bjorn.x.larsson@telia.com>
Cc: Ryan Pallas <derokorian@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] set_exception_handler catches all Throwables
From: aharvey@php.net (Adam Harvey)

On 19 August 2015 at 07:20, Bj=C3=B6rn Larsson <bjorn.x.larsson@telia.com> =
wrote:
> Den 2015-08-19 kl. 15:55, skrev Ryan Pallas:
>> I agree with this completely. I think the point here is that
>> catch(Exception $e) remains unchanged while setting a handler actually
>> catches more things now. Tbh I feel like this is an oversight in
>> implementing the Error/Throwable rfc and should be addressed now, otherw=
ise
>> it can't be changed until 8 if I understand correctly.
>>
> This is also a view that I share, feels more consistent that the handler
> mimics v5 and catch(Exception $e) behaviour. Hope there can be a
> decision / consensus on this topic.

I think this is absolutely an improvement, for what it's worth.
set_exception_handler(), by definition, is a last resort handler that
should be getting used primarily for logging and cleaning up, since
execution stops once it's done.

What I don't want is another path that has to be monitored to make
sure you catch every error/exception case that terminates execution.
Two callbacks is already arguably one too many, and just excluding
non-Exception Throwable objects and letting them fall through to the
error handler feels like we did a lot of work for little practical
reward.

Adam