Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126121
Precedence: bulk
MIME-Version: 1.0
References: <CA+NMNO1zgCLLDOaWhqg8ipOrLETRn3w_91JNdCJz0zrKmeRWyg@mail.gmail.com>
 <8f268a8e-1646-455e-a1c2-b030581dcb9f@bastelstu.be> <CA+NMNO1LOXwLiRs51p-QnVkcs829RHxpZkC=ZArhFUTz6Qg-aA@mail.gmail.com>
 <a2fc46c291cb765dbfc7f4fa05f0cffc@bastelstu.be>
In-Reply-To: <a2fc46c291cb765dbfc7f4fa05f0cffc@bastelstu.be>
Reply-To: erictnorris@gmail.com
Date: Tue, 10 Dec 2024 23:49:54 -0500
Message-ID: <CA+NMNO3LcoMjepmdhgU54GTf8VcumgSLC5Op6R=_bH7qude+Ow@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Error backtraces v2
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
From: eric.t.norris@gmail.com (Eric Norris)

> 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.

I've updated the RFC to v2.0: I'm now proposing an on-off switch to
enable backtraces for fatal errors only.

That said, after updating the RFC I've discussed an alternative with
my colleagues that I think is worth also discussing here. It occurred
to me that the main issue is including the backtrace in
error_get_last, but we want the backtrace in error_get_last as there
is no other way for user code to get the backtrace for a fatal error,
aside from calling error_get_last in shutdown code.

If instead we did call the error handler set up in set_error_handler -
or call something like that - users could gather the backtrace with
debug_backtrace themselves, and log it how they want, or send it
elsewhere, whatever. Internally PHP wouldn't need to do anything about
the backtrace.

Of course users should not be able to actually handle fatal errors,
and execution should immediately bail out after calling the handler as
it does today upon encountering a fatal error. This could be addressed
by either informing users that returning true or false makes no
difference for fatal errors, or by introducing a newer error handler
concept that had that behavior. There may be a backwards compatibility
issue with the former - users might not have written their error
handling code with the expectation that it could encounter fatal
errors - and that too could be addressed by either making this an INI
setting, or again, introducing a newer error handler concept.

Either way, exposing fatal errors to user-level code may be a better
solution to the problem of errors not having a backtrace. Passing
fatal errors to user handler code would potentially make error
handling more consistent, and rely less on global state like
error_get_last. Also note that calling user-level code after a fatal
error is not new; user code registered in register_shutdown_function
is called after a fatal error, which again is one source of a need for
something like error_get_last.

I'm curious if anyone has any immediate reactions - positive or
negative - to this line of thinking. Perfect is the enemy of good, so
I'd accept moving forward with the RFC as it is now if it is more
tenable; I think this idea is worth exploring a little bit before
doing so, however.