[Filesystem] Fix dumpFile stat failed error hitting custom handler
#54878
Conversation
Since symfony#54471, dumpFile will trigger a `fileperms(): stat failed` error when writing to a filename that does not yet exist. This was silenced from PHP's default handler with the `@` operator. However, the error is still passed to any custom handler that the application has registered, and can therefore cause exceptions or spurious logging depending on the implementation of the handler. The better solution, which is consistent with all other calls to native functions in this class, would be to use `self::box` to catch and ignore the potential error so that it never leaks outside this class.
|
As far as I can see the coding standards and test failures are unrelated to the change in this branch - but please let me know if you want any changes. |
|
The proposed solution works for me but:
This is still an error in the custom error handler if it doesn't respect the silencing of errors and should be fixed nonetheless as an error handler throwing no matter if the error was silenced can still throw too eagerly. |
That's probably true. At the same time, I don't think a library should be relying on the silencing operator to suppress errors that are emitted during expected usage of a method - in particular if it hasn't done so in the past, since this might break existing applications where the over-eager throw has not historically caused any problems. |
carsonbot
changed the title
stat failed error hitting custom handlerstat failed error hitting custom handler
carsonbot
changed the title
stat failed error hitting custom handlerstat failed error hitting custom handler
|
Thank you @acoulton. |
Since #54471, dumpFile will trigger a
fileperms(): stat failederror when writing to a filename that does not yet exist. This was silenced from PHP's default handler with the@operator.However, the error is still passed to any custom handler that the application has registered, and can therefore cause exceptions or spurious logging depending on the implementation of the handler.
The better solution, which is consistent with all other calls to native functions in this class, would be to use
self::boxto catch and ignore the potential error so that it never leaks outside this class.