Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110420
MIME-Version: 1.0
References: <CAGgaK7KScGnNaCSnz6szCzJ3jndoipH0=yonW6FPKR7GbkPdLw@mail.gmail.com>
 <CA+kxMuRVwhMjZxA0ctz4PK9VNvNTYSga6bg1V54KeqHXMguQgw@mail.gmail.com> <CAGgaK7JJO8bit-dADUpP013PgiyvKzd6Jy6anemwzTkx4UpiUA@mail.gmail.com>
In-Reply-To: <CAGgaK7JJO8bit-dADUpP013PgiyvKzd6Jy6anemwzTkx4UpiUA@mail.gmail.com>
Date: Mon, 8 Jun 2020 11:40:57 +0100
Message-ID: <CA+kxMuSMq+Ttd2bUzwV3Uh=pAiyotdLFQr0d6O7h=fMwmTOXpw@mail.gmail.com>
To: Max Semenik <maxsem.wiki@gmail.com>
Cc: Internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] RFC: Error backtraces
From: Danack@basereality.com (Dan Ackroyd)

On Tue, 2 Jun 2020 at 21:57, Max Semenik <maxsem.wiki@gmail.com> wrote:
>
> Thanks for your input!
>

> The problem with this is that it doesn't get called on fatal errors,

That would be an easier and smaller thing to fix, rather than also
changing error/warning handling.

A stack trace shown on fatal errors that doesn't include any variables
would be a useful thing imo.

> I don't see leaks via traces as a serious problem.

That is an opinion not universally shared.

I know one company that failed a security audit, and so failed to win
a contract, due to variables being exposed in stacktraces that reached
their log files.

> Your solution requires programmers to write code
> supporting this kind of workflow,

Sorry, not sure what you mean.

The changes would be internal, and then would naturally reach the
users outer exception handler, where they should already have logging
of uncaught exceptions. So can't see why it would be a problem.

> Sorry, didn't realize the word is, uh, "informal".

Informal? _Infernal_ more like. *ba-dum-tish*

Danack wrote:
>> That depends on what callback function has been set for
>> 'set_exception_handler'.
Max wrote:
> From my reading of the code, backtraces are generated on object creation,

I meant that whether the trace is converted to a string and logged
anywhere is dependent on what the exception handler chooses to do.

> INI setting should take care of this.

People really, really really, _really_ don't  like ini settings.

Although application level ini settings can be appropriate in some
cases, a new ini setting here doesn't feel like a great choice.

Combine that with "As shown in the example output, traces are saved as
string" and I really don't like it.

We want to make it possible to decide what to do with errors programmatically.

Converting stack traces to strings before a user handler can decide
what to do with them is not a good approach.

To summarise, adding stack trace to fatal error output (without
variables) sounds good to me, and the idea I said before of adding
exceptions to errors/warning would allow better user control over what
happens also sounds good, but more ini settings and traces as strings
sounds not good.

cheers
Dan
Ack