c927c481aa
This PR was merged into the 3.4 branch.
Discussion
----------
[Console][DI] Fail gracefully
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | https://github.com/symfony/flex/issues/212, #25280
| License | MIT
| Doc PR | -
I already experienced this issue a few times without spending time digging it:
sometimes, you call `cache:clear`, and the command quits without any output, and with 255 status code.
The reason is the `@include` in `Kernel`, which makes everything silent, especially fatal errors (thanks PHP...)
So if the to-be-removed container is broken for some fatal reason, the failure is really bad.
To fix that, here are two measures:
- use `include_once` instead of `require_once` in the dumped container: that's OK there to actually not immediately load the file, any hard failure will happen later anyway, and any soft failure will allow the `cache:clear` command to complete (like when you remove a package)
- register `Application::renderException()` as the main PHP exception handler, via `Debug::ErrorHandler` when it's available
End result when it fails:
instead of a blank output.
Commits
-------
|
||
|---|---|---|
| .. | ||
| config | ||
| containers | ||
| directory | ||
| graphviz | ||
| includes | ||
| ini | ||
| php | ||
| Prototype | ||
| xml | ||
| yaml | ||
| array.json | ||
| Bar.php | ||
| BarInterface.php | ||
| CaseSensitiveClass.php | ||
| CustomDefinition.php | ||
| DeprecatedClass.php | ||
| FactoryDummy.php | ||
| NamedArgumentsDummy.php | ||
| ParentNotExists.php | ||
| SimilarArgumentsDummy.php | ||
| StubbedTranslator.php | ||
| TestServiceSubscriber.php | ||
