On Tue, 2 Jun 2020 at 21:57, Max Semenik <maxsem.w...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
