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.
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
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]
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:
On 21 October 2017 11:41:46 BST, "Christoph M. Becker" cmbecker69@gmx.de
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]