Hi,
We're trying to use TYPO3 on PHP7 and have the problem that throwables
get passed to the exception handler because 'set_exception_handler()'
does send all throwables to the handler, not only exceptions.
Is this intended, or should a "set_throwable_handler()" function be
introduced instead?
Example: http://3v4l.org/b5iV6
--
Regards,
Christian Weiske
Regards/Mit freundlichen Grüßen
Christian Weiske
-= Geeking around in the name of science since 1982 =
This is intended and documented here:
http://php.net/manual/en/function.set-exception-handler.php
Regards, Niklas
2015-08-17 12:31 GMT+02:00 Christian Weiske cweiske@cweiske.de:
Hi,
We're trying to use TYPO3 on PHP7 and have the problem that throwables
get passed to the exception handler because 'set_exception_handler()'
does send all throwables to the handler, not only exceptions.Is this intended, or should a "set_throwable_handler()" function be
introduced instead?Example: http://3v4l.org/b5iV6
--
Regards,
Christian WeiskeRegards/Mit freundlichen Grüßen
Christian Weiske-= Geeking around in the name of science since 1982 =
Hello Niklas,
This is intended and documented here:
http://php.net/manual/en/function.set-exception-handler.php
If "Documented" means the note
Note that providing an explicit Exception type hint for the ex
parameter in your callback will cause issues with the changed
exception hierarchy in PHP 7.
then yes, it's documented.
But I'd not see this as documented or rather liked a more explicit
mention of Throwables there.
--
Regards/Mit freundlichen Grüßen
Christian Weiske
-= Geeking around in the name of science since 1982 =
This is intended and documented here:
http://php.net/manual/en/function.set-exception-handler.phpIf "Documented" means the note
Note that providing an explicit Exception type hint for the ex
parameter in your callback will cause issues with the changed
exception hierarchy in PHP 7.then yes, it's documented.
But I'd not see this as documented or rather liked a more explicit
mention of Throwables there.
Actually, I don't call this intended. This is just as much as a BC break
as the original implementation where Errors where also Exceptions. IMO,
set_exception_handler() should be changed - with my preference it not
capturing Error, and instead have an additional set_throwable_handler().
cheers,
Derick
Am 17.08.2015 um 16:00 schrieb Derick Rethans:
Actually, I don't call this intended. This is just as much as a BC break
as the original implementation where Errors where also Exceptions. IMO,
set_exception_handler()should be changed - with my preference it not
capturing Error, and instead have an additional set_throwable_handler().
+1
Am 17.08.2015 um 16:00 schrieb Derick Rethans:
Actually, I don't call this intended. This is just as much as a BC break
as the original implementation where Errors where also Exceptions. IMO,
set_exception_handler()should be changed - with my preference it not
capturing Error, and instead have an additional set_throwable_handler().+1
What's the plan for set_exception_handler() regarding Throwables? Seeing as
we're now in the RC release phase I think this bone of contention should be
resolved one way or another as soon as we can.
Den 2015-08-19 kl. 10:52, skrev Peter Cowburn:
Am 17.08.2015 um 16:00 schrieb Derick Rethans:
Actually, I don't call this intended. This is just as much as a BC break
as the original implementation where Errors where also Exceptions. IMO,
set_exception_handler()should be changed - with my preference it not
capturing Error, and instead have an additional set_throwable_handler().
+1What's the plan for
set_exception_handler()regarding Throwables? Seeing as
we're now in the RC release phase I think this bone of contention should be
resolved one way or another as soon as we can.
Yes, a "global" function that behaves differently between PHP 5 & 7 is
not optimal in
my view. I'm also wondering how to make one handler managing two
different type
of situations. @ircmaxwell described it in Core functions throwing
exceptions in PHP7:
"Errors signify programmer error, where Exceptions signify
unknown or runtime errors. Meaning that an Error should always be a
problem with your code, but an Exception could be a systems problem, a
user problem or a problem in your code."
/Cheers //Björn Larsson/
PS A bit new to this list but hope to have contributed a little :)
What do you guys do in the set_exception_handler callback? Wouldn't most
code just use the same callback and just log the error / exception?
Regards, Niklas
2015-08-19 11:55 GMT+02:00 Björn Larsson bjorn.x.larsson@telia.com:
Den 2015-08-19 kl. 10:52, skrev Peter Cowburn:
Am 17.08.2015 um 16:00 schrieb Derick Rethans:
Actually, I don't call this intended. This is just as much as a BC break
as the original implementation where Errors where also Exceptions. IMO,
set_exception_handler()should be changed - with my preference it not
capturing Error, and instead have an additional set_throwable_handler().+1
What's the plan for
set_exception_handler()regarding Throwables? Seeing
as
we're now in the RC release phase I think this bone of contention should
be
resolved one way or another as soon as we can.Yes, a "global" function that behaves differently between PHP 5 & 7 is not
optimal in
my view. I'm also wondering how to make one handler managing two
different type
of situations. @ircmaxwell described it in Core functions throwing
exceptions in PHP7:
"Errors signify programmer error, where Exceptions signify
unknown or runtime errors. Meaning that an Error should always be a
problem with your code, but an Exception could be a systems problem, a
user problem or a problem in your code."/Cheers //Björn Larsson/
PS A bit new to this list but hope to have contributed a little :)
Plan to migrate to PHP 7 later, like the new Exception/Error way
of working very much. Point is that current set_exception_handler
only address exceptions, not errors. You are right that on that the
surface it's the same callback, but could eg be logging in different
ways and to different recipients. Will look into it more later.
Regards, //Björn
Den 2015-08-19 kl. 13:30, skrev Niklas Keller:
What do you guys do in the set_exception_handler callback? Wouldn't
most code just use the same callback and just log the error / exception?Regards, Niklas
2015-08-19 11:55 GMT+02:00 Björn Larsson <bjorn.x.larsson@telia.com
mailto:bjorn.x.larsson@telia.com>:Den 2015-08-19 kl. 10:52, skrev Peter Cowburn: On 17 August 2015 at 15:24, Sebastian Bergmann <sebastian@php.net> wrote: Am 17.08.2015 um 16:00 schrieb Derick Rethans: Actually, I don't call this intended. This is just as much as a BC break as the original implementation where Errors where also Exceptions. IMO, `set_exception_handler()` should be changed - with my preference it not capturing Error, and instead have an additional set_throwable_handler(). +1 What's the plan for `set_exception_handler()` regarding Throwables? Seeing as we're now in the RC release phase I think this bone of contention should be resolved one way or another as soon as we can. Yes, a "global" function that behaves differently between PHP 5 & 7 is not optimal in my view. I'm also wondering how to make one handler managing two different type of situations. @ircmaxwell described it in *Core functions throwing exceptions in PHP7*: "Errors signify programmer error, where Exceptions signify unknown or runtime errors. Meaning that an Error should always be a problem with your code, but an Exception could be a systems problem, a user problem or a problem in your code." /Cheers //Björn Larsson/ PS A bit new to this list but hope to have contributed a little :)
Plan to migrate to PHP 7 later, like the new Exception/Error way
of working very much. Point is that current set_exception_handler
only address exceptions, not errors. You are right that on that the
surface it's the same callback, but could eg be logging in different
ways and to different recipients. Will look into it more later.Regards, //Björn
Den 2015-08-19 kl. 13:30, skrev Niklas Keller:
What do you guys do in the set_exception_handler callback? Wouldn't most
code just use the same callback and just log the error / exception?Regards, Niklas
2015-08-19 11:55 GMT+02:00 Björn Larsson <bjorn.x.larsson@telia.com
mailto:bjorn.x.larsson@telia.com>:Den 2015-08-19 kl. 10:52, skrev Peter Cowburn: On 17 August 2015 at 15:24, Sebastian Bergmann <sebastian@php.net> wrote: Am 17.08.2015 um 16:00 schrieb Derick Rethans: Actually, I don't call this intended. This is just as much as a BC break as the original implementation where Errors where also Exceptions. IMO, `set_exception_handler()` should be changed - with my preference it not capturing Error, and instead have an additional set_throwable_handler(). +1
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, otherwise
it can't be changed until 8 if I understand correctly.
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, otherwise
it can't be changed until 8 if I understand correctly.
The difference is that catch (Exception $e) can be found in many places,
whereas set_exception_handler is a global per application thing.
Regards, Niklas
Den 2015-08-19 kl. 15:55, skrev Ryan Pallas:
On Aug 19, 2015 6:44 AM, "Björn Larsson" <bjorn.x.larsson@telia.com
mailto:bjorn.x.larsson@telia.com> wrote:Plan to migrate to PHP 7 later, like the new Exception/Error way
of working very much. Point is that current set_exception_handler
only address exceptions, not errors. You are right that on that the
surface it's the same callback, but could eg be logging in different
ways and to different recipients. Will look into it more later.Regards, //Björn
Den 2015-08-19 kl. 13:30, skrev Niklas Keller:
What do you guys do in the set_exception_handler callback? Wouldn't
most code just use the same callback and just log the error / exception?Regards, Niklas
2015-08-19 11:55 GMT+02:00 Björn Larsson <bjorn.x.larsson@telia.com
mailto:bjorn.x.larsson@telia.com <mailto:bjorn.x.larsson@telia.com
mailto:bjorn.x.larsson@telia.com>>:Den 2015-08-19 kl. 10:52, skrev Peter Cowburn: On 17 August 2015 at 15:24, Sebastian Bergmann <sebastian@php.net <mailto:sebastian@php.net>> wrote: Am 17.08.2015 um 16:00 schrieb Derick Rethans: Actually, I don't call this intended. This is just as much as a BC break as the original implementation where Errors where also Exceptions. IMO, `set_exception_handler()` should be changed - with my preference it not capturing Error, and instead have an additional set_throwable_handler(). +1I 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,
otherwise 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.
Regards //Björn
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, otherwise
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
Hi!
Actually, I don't call this intended. This is just as much as a BC break
as the original implementation where Errors where also Exceptions. IMO,
set_exception_handler()should be changed - with my preference it not
capturing Error, and instead have an additional set_throwable_handler().
Could you explain why? As I understand, set_exception_handler() is
needed to provide a backstop for the cases when all else fails and allow
for ordered shutdown, nice error message, logging, etc. With this in
mind, catching all Throwable's is well within this function. So what
would be the case for having two separate functions for this task and
what would be the case for using one that only catches half of the
runaway exceptions (throwables) but not the other half?
Stas Malyshev
smalyshev@gmail.com
Stas and all,
Hi!
Actually, I don't call this intended. This is just as much as a BC break
as the original implementation where Errors where also Exceptions. IMO,
set_exception_handler()should be changed - with my preference it not
capturing Error, and instead have an additional set_throwable_handler().Could you explain why? As I understand,
set_exception_handler()is
needed to provide a backstop for the cases when all else fails and allow
for ordered shutdown, nice error message, logging, etc. With this in
mind, catching all Throwable's is well within this function. So what
would be the case for having two separate functions for this task and
what would be the case for using one that only catches half of the
runaway exceptions (throwables) but not the other half?
This is a very important point that bears repeating. The difference is
that if an exception handler is called, the script will terminate
after the handler is called.
The point in separating catch(exception) from catch(throwable) was
that the prior can be done in specific circumstances where the only
reason an exception was thrown was because of a specific failure
(which could be worked around). Adding throwables changes that
contract, and hence was made to not inherit from Exception.
But this case, the exception handler should purely be a logging /
pretty error to user. This isn't a "best practice" distinction either
because since execution terminates afterwards there isn't much you can
do (you can't even call the exception handler again).
So in this case, I don't really see the distinction here that would
warrant splitting it into separate functions. If it was like
error_handler where you could return false and resume, I'd be 100% on
board. But as it is today, I don't see why separating it would be
beneficial (what's the use-case where you need to split it).
Anthony
Hi!
We're trying to use TYPO3 on PHP7 and have the problem that throwables
get passed to the exception handler because 'set_exception_handler()'
does send all throwables to the handler, not only exceptions.
Why this is a problem for TYPO3? How they use set_exception_handler()
that catching errors there breaks it?
Stas Malyshev
smalyshev@gmail.com