Dear all,
a couple of weeks ago, I proposed a change to the handling of the situation
where methods are called on non-objects. Instead of an E_ERROR, the engine would
raise an E_RECOVERABLE_ERROR, and enable framework and library authors to handle
this.
An intriguing usecase from my POV is to make use of this in tools like PHPUnit;
instead of just printing a fatal error in the middle of a test run and exiting,
the tools can decide to raise an exception and display the very much more
helpful backtrace. No third-party PHP extensions needed for this, just a simple
set_error_handler() call [1].
I've verified various places like phpdbg and added a bunch of tests and am glad
to extend that should anyone come up with a situation he/she feel this would
behave in an unstable manner; athough this is realized in a somewhat similar
manner to type hint mismatches, which have proven to be quite stable.
Anyhow, I'd now like to see where we'd come out at and would kindly ask you to
vote for or against inclusion of this feature:
https://wiki.php.net/rfc/catchable-call-to-member-of-non-object#vote
Thanks in advance!
-Timm
1:
https://wiki.php.net/rfc/catchable-call-to-member-of-non-object#exampleexceptions
Dear all,
a couple of weeks ago, I proposed a change to the handling of the situation
where methods are called on non-objects. Instead of an E_ERROR, the engine
would
raise an E_RECOVERABLE_ERROR, and enable framework and library authors to
handle
this.An intriguing usecase from my POV is to make use of this in tools like
PHPUnit;
instead of just printing a fatal error in the middle of a test run and
exiting,
the tools can decide to raise an exception and display the very much more
helpful backtrace. No third-party PHP extensions needed for this, just a
simple
set_error_handler()call [1].I've verified various places like phpdbg and added a bunch of tests and am
glad
to extend that should anyone come up with a situation he/she feel this
would
behave in an unstable manner; athough this is realized in a somewhat
similar
manner to type hint mismatches, which have proven to be quite stable.Anyhow, I'd now like to see where we'd come out at and would kindly ask
you to
vote for or against inclusion of this feature:https://wiki.php.net/rfc/catchable-call-to-member-of-non-object#vote
Any plans to close the voting, Timm?
Thanks in advance!
-Timm
1:
https://wiki.php.net/rfc/catchable-call-to-member-of-non-object#exampleexceptions
Hi,
Peter Cowburn petercowburn@gmail.com hat am 20. Juli 2014 um 17:42
geschrieben:
[...]Anyhow, I'd now like to see where we'd come out at and would kindly ask
you to
vote for or against inclusion of this feature:https://wiki.php.net/rfc/catchable-call-to-member-of-non-object#vote
Any plans to close the voting, Timm?
You're right, I forgot about adding an end date when I started the vote back in
the End of June.
I've set the voting end to 2014-07-30. I think four weeks sounds like a
reasonable time frame.
-Timm
You're right, I forgot about adding an end date when I started the vote back in
the End of June.I've set the voting end to 2014-07-30. I think four weeks sounds like a
reasonable time frame.
Please don’t. Most RFCs are only voted on for one or two weeks, that’s perfectly fine for this RFC. It’s also not a terribly controversial one.
I’d suggest ending it next Friday.
--
Andrea Faulds
http://ajf.me/
Please don’t. Most RFCs are only voted on for one or two weeks, that’s perfectly fine for this RFC. It’s also not a terribly controversial one.
I’d suggest ending it next Friday.
Haha, disregard that, I can’t read.
--
Andrea Faulds
http://ajf.me/
Hi Timm,
a couple of weeks ago, I proposed a change to the handling of the situation
where methods are called on non-objects. Instead of an E_ERROR, the engine
would
raise an E_RECOVERABLE_ERROR, and enable framework and library authors to
handle
this.An intriguing usecase from my POV is to make use of this in tools like
PHPUnit;
instead of just printing a fatal error in the middle of a test run and
exiting,
the tools can decide to raise an exception and display the very much more
helpful backtrace. No third-party PHP extensions needed for this, just a
simple
set_error_handler()call [1].I've verified various places like phpdbg and added a bunch of tests and am
glad
to extend that should anyone come up with a situation he/she feel this
would
behave in an unstable manner; athough this is realized in a somewhat
similar
manner to type hint mismatches, which have proven to be quite stable.Anyhow, I'd now like to see where we'd come out at and would kindly ask
you to
vote for or against inclusion of this feature:https://wiki.php.net/rfc/catchable-call-to-member-of-non-object#vote
Thanks in advance!
I like the idea.
Only thing that I don't like is it depends on error message to be useful
rather than error code/status. Was this discussed? Just curious.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hello,
Yasuo Ohgaki yohgaki@ohgaki.net hat am 27. Juli 2014 um 10:11 geschrieben:
Hi Timm,
On Sun, Jun 29, 2014 at 7:40 PM, Timm Friebe <php@thekid.de
mailto:php@thekid.de > wrote:
> > a couple of weeks ago, I proposed a change to the handling of the
situationwhere methods are called on non-objects. Instead of an E_ERROR, the
engine would
raise an E_RECOVERABLE_ERROR, and enable framework and library authors to
handle
this.
[...]I like the idea.
Only thing that I don't like is it depends on error message to be useful
rather than error code/status. Was this discussed? Just curious.
No, this wasn't discussed so far. You're right, this could make the code inside
the error handler more readable and robust. It would mean, however, changing all
the other E_RECOVERABLE_ERRORs too, like argument type mismatching and certain
closure and generator operations; and thus was out of scope.
I remember this from a couple of years back though; but can't recall why it was
never done.
-Timm
Hi Timm,
Only thing that I don't like is it depends on error message to be useful
rather than error code/status. Was this discussed? Just curious.No, this wasn't discussed so far. You're right, this could make the code
inside
the error handler more readable and robust. It would mean, however,
changing all
the other E_RECOVERABLE_ERRORs too, like argument type mismatching and
certain
closure and generator operations; and thus was out of scope.I remember this from a couple of years back though; but can't recall why
it was
never done.
Looking forward new RFC.
We are better to have cleaner API.
Optional parameter for user defined error handler is adequate, probably.
Addition to error context is the cleanest, perhaps.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net