> 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.
