Wouldn't Exception::getContext() be useful?

php.internals

Michael Morris

8 years ago
Right now the only way I know of to see the context of an exception throw is to pass it in.. throw new CustomException(get_definted_vars()); It would be very useful to have exceptions just have this as a method. set_error_handle had this ability, but it's now deprecated. I'm guessing there's an engine reason why this hasn't happened because it seems like a pretty obvious include to the default methods of the Exception and Error objects.

Christoph Becker

8 years ago
On 21.10.2017 at 09:20, Michael Morris wrote:
> Right now the only way I know of to see the context of an exception throw > is to pass it in.. > > throw new CustomException(get_definted_vars()); > > It would be very useful to have exceptions just have this as a method. > set_error_handle had this ability, but it's now deprecated. I'm guessing > there's an engine reason why this hasn't happened because it seems like a > pretty obvious include to the default methods of the Exception and Error > objects.
Quite likely the same reasoning as for deprecating the $errcontext argument applies, see <https://wiki.php.net/rfc/deprecations_php_7_2#errcontext_argument_of_error_handler>.
-- Christoph M. Becker

Rowan Collins

8 years ago
On 21 October 2017 11:41:46 BST, "Christoph M. Becker" <cmbecker69@gmx.de> wrote:
>On 21.10.2017 at 09:20, Michael Morris wrote: > >> Right now the only way I know of to see the context of an exception >throw >> is to pass it in.. >> >> throw new CustomException(get_definted_vars()); >> >> It would be very useful to have exceptions just have this as a >method. >> set_error_handle had this ability, but it's now deprecated. I'm >guessing >> there's an engine reason why this hasn't happened because it seems >like a >> pretty obvious include to the default methods of the Exception and >Error >> objects. > >Quite likely the same reasoning as for deprecating the $errcontext >argument applies, see ><https://wiki.php.net/rfc/deprecations_php_7_2#errcontext_argument_of_error_handler>.
See also my posts about the problems of capturing arguments in the exception's backtrace (sorry, don't have an archive link to hand). Basically, holding references to objects without user interaction makes object lifetimes unpredictable and serialization unexpectedly fail. Did you just want this for debugging, or was there some other use case? Regards,
-- Rowan Collins [IMSoP]

Michael Morris

8 years ago
Just for debugging. I've been mulling over how to improve exception/error handling in Drupal 8 out of the box. On Sat, Oct 21, 2017 at 10:31 AM, Rowan Collins <rowan.collins@gmail.com> wrote: