Hi
Am 2024-12-06 02:08, schrieb Eric Norris:
The “php.ini Defaults” section should probably refer to the voting
widget as well.
The first voting widget would probably be better phrased as:
"Add the 'error_backtrace_recording' INI as described?"
I'm a little nervous about this change, because I was hoping to be a
little more open-ended. For example, I'm not tied to the name
'error_backtrace_recording', so I wouldn't want someone to vote 'no'
because they didn't like the setting name. Secondly, maybe we don't
want the zend global (which I'll actually get to in a bit), and
similarly I wouldn't want someone to vote 'no' because of that; I
don't actually care about whether it's a global or not, I only care
about getting backtraces for fatal errors.
I believe RFCs should be sufficiently precise so that one is able to
implement the proposal reasonably unambiguously based on the RFC text
alone. Given that you are concerned about the INI setting causing the
RFC not to pass, it should be evident that this is such an important
topic that it needs the RFC to be clear about what is proposed for
voters to be able to vote on the full picture.
Normally one would expect the "Unlocked" to be printed between "Done"
and "After", but this is not the case, because the Exception in the
global keeps a reference to $lock within its backtrace. This would be
the same if the Exception would instead be a `trigger_error()` that
remains available via `error_get_last()`.
In other words, we would have a INI setting that changes application
behavior in subtle ways, which is a no-no.
Great example, thank you. Since you are stating this is problematic -
and I don't necessarily disagree - does this make allowing backtraces
as implemented for non-fatal errors a non-starter? Presumably having a
backtrace for a fatal error doesn't matter since everything will soon
be destroyed in the process of shutting down.
Yes, I agree that having a stacktracke for fatal errors is a non-issue.
For non-fatal errors the INI setting definitely is a problem.
Unconditionally having a stacktrace for non-fatal errors I'm am not yet
sure if this would be a problem or if it would be fine if it is a
RFC-agreed-upon (breaking) change. Given that it's common to turn
warnings and notices into Exceptions and thus to treat them as hard
errors, I'd be inclined to say that the value-add of having backtraces
for them is fairly small compared to the possible impact and that it
makes sense not to include this in the RFC at all.
For the previous RFC this apparently was a non-issue, because the
stack
was stored as a string. But for your RFC this is an issue, because
based
on the tests it's stored as an array.
I would have preferred to make this a parameter to zend_error_cb, but
I thought that changing the signature of that method might be too much
of a backwards compatibility break (though this would only affect
extensions). Making it a parameter would shorten the lifetime of the
Making breaking changes to the internal API is generally fine if there
is a reason for making the change.
Best regards
Tim Düsterhus
