Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110319
MIME-Version: 1.0
References: <CAGgaK7KScGnNaCSnz6szCzJ3jndoipH0=yonW6FPKR7GbkPdLw@mail.gmail.com>
In-Reply-To: <CAGgaK7KScGnNaCSnz6szCzJ3jndoipH0=yonW6FPKR7GbkPdLw@mail.gmail.com>
Date: Sun, 31 May 2020 15:47:18 +0200
Message-ID: <CAF+90c_X97zYntHqtWQviGK2WjseCSDaH-0nbHQvO=u2uhRFKw@mail.gmail.com>
To: Max Semenik <maxsem.wiki@gmail.com>
Cc: Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000aa7d6705a6f1ebf7"
Subject: Re: [PHP-DEV] RFC: Error backtraces
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000aa7d6705a6f1ebf7
Content-Type: text/plain; charset="UTF-8"

On Fri, May 29, 2020 at 8:24 PM Max Semenik <maxsem.wiki@gmail.com> wrote:

> Hi, I'd like to present a new RFC for your consideration:
> https://wiki.php.net/rfc/error_backtraces
>
> In a nutshell, I'm proposing to give errors equal rights with exceptions
> and provide backtraces for them, too.
>

I'm concerned about the performance implications of this change. Backtrace
gathering is quite expensive and doing this for every diagnostic will have
a large performance impact if there are many of them. This is okay if your
code is intended to be diagnostics clean, but unfortunately this is not a
given. If you generate 10k deprecation warnings during a request, you're
definitely going to feel those backtraces.

It is already possible to get a backtrace for all non-fatal diagnostics
through a custom error handler, which allows you to control whether you
want to collect a backtrace for a particular error. As such, I would
recommend to limit this functionality to fatal errors only, where such a
possibility does not currently exist. Additionally fatal errors also
naturally limit the performance impact, because there can (approximately)
be only one fatal error per request.

Nikita

--000000000000aa7d6705a6f1ebf7--