I understand the $errcontext argument to the set_error_level()
callback was deprecated in 7.2.
Apparently, this was deemed "not useful", but what's the alternative?
I understand that debug_backtrace() reports the arguments on the
call-stack, but... just the arguments - no local vars.
I understand you want people to use a real debugger, but there's also
such a thing as error-handling in production - this information was
logged and was useful in conjunction with Sentry, and probably other
error-handlers.
But this feature has been removed, and there's no alternative?
I understand the $errcontext argument to the set_error_level()
callback was deprecated in 7.2.Apparently, this was deemed "not useful", but what's the alternative?
Digging into the archives, and the RFC [1], there was a bit more to it
than "not useful"; capturing all variables in a local scope and making
them available somewhere else is problematic when it comes to
optimisation and analysis. This is particularly true since PHP has no
way of making this data immutable, so any error can theoretically cause
any local object to change state without being mentioned.
While I can understand the desire to have debugging feature built into
the language "out of the box", it may be best left to extensions which
can capture the information to a log or wherever without providing the
full flexibility of the language to interact with it.
[1]
https://wiki.php.net/rfc/deprecations_php_7_2#errcontext_argument_of_error_handler
Regards,
--
Rowan Collins
[IMSoP]
While I can understand the desire to have debugging feature built into
the language "out of the box", it may be best left to extensions which
can capture the information to a log or wherever without providing the
full flexibility of the language to interact with it.
I think, since the language did provide this "out of the box", it's sort of
odd to deprecate a feature that is being used by a popular product - the
Sentry PHP package has 8 million downloads, and PHP developers rely
on this in production to help them fix bugs. Seems pretty important?
And an extension isn't really an acceptable alternative to someone who
was offering a product that "just worked".
For example, rather than removing this feature, might it be possible to
deeply clone the variables and provide backwards compatibility in that
manner? I doubt that anyone is counting on introducing side-effects via
an error-handler, but surely it's not uncommon for error-aggregators and
loggers to rely on this information being available?
While I can understand the desire to have debugging feature built into
the language "out of the box", it may be best left to extensions which
can capture the information to a log or wherever without providing the
full flexibility of the language to interact with it.I think, since the language did provide this "out of the box", it's sort of
odd to deprecate a feature that is being used by a popular product - the
Sentry PHP package has 8 million downloads, and PHP developers rely
on this in production to help them fix bugs. Seems pretty important?And an extension isn't really an acceptable alternative to someone who
was offering a product that "just worked".For example, rather than removing this feature, might it be possible to
deeply clone the variables and provide backwards compatibility in that
manner? I doubt that anyone is counting on introducing side-effects via
an error-handler, but surely it's not uncommon for error-aggregators and
loggers to rely on this information being available?
According to the sentry people here https://github.com/getsentry/sentry-php/issues/662#issuecomment-426550180
they don't actually use that anymore:
I've done a little bit of digging here and there, and luckily this seems a non-issue for us! ?
In the 2.0 branch that argument is not used: