On Wed, Jun 3, 2020 at 9:04 AM Nikita Popov wrote:
> On Tue, Jun 2, 2020 at 10:57 PM Max Semenik wrote:
>
>> On Sun, May 31, 2020 at 4:47 PM Nikita Popov
>> wrote:
>>
>> > I'm concerned about the performance implications of this change.
>> Backtrace
>> > gathering is quite expensive and doing t
On Tue, 2 Jun 2020 at 21:57, Max Semenik 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'
On Tue, Jun 2, 2020 at 10:57 PM Max Semenik wrote:
> On Sun, May 31, 2020 at 4:47 PM Nikita Popov wrote:
>
> > 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 imp
Thanks for your input!
On Sat, May 30, 2020 at 8:36 PM Dan Ackroyd wrote:
> For my own code, I convert all non-silenced errors and warnings into
> an exception through the error handler*. That works pretty well, but
> has one big downside - it only throws one type of exception.
>
> I wrote some
On Fri, May 29, 2020 at 8:24 PM Max Semenik 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 th
On Fri, 29 May 2020 at 19:23, Max Semenik wrote:
>
> Hi, I'd like to present a new RFC for your consideration:
> https://wiki.php.net/rfc/error_backtraces
>
Hi Max,
I've also been thinking about how errors + warnings can be improved also.
For my own code, I convert all non-silenced errors and
