This PR was squashed before being merged into the 3.4 branch (closes#32800).
Discussion
----------
Improve some URLs
| Q | A
| ------------- | ---
| Branch? | 3.4 <!-- see below -->
| Bug fix? | no
| New feature? | no <!-- please update src/**/CHANGELOG.md files -->
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass? | yes <!-- please add some, will be required by reviewers -->
| Fixed tickets | N/A <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | N/A <!-- required for new features -->
<!--
Replace this notice by a short README for your feature/bugfix. This will help people
understand your PR and can be used as a start for the documentation.
Additionally (see https://symfony.com/roadmap):
- Bug fixes must be submitted against the lowest maintained branch where they apply
(lowest branches are regularly merged to upper ones so they get the fixes too).
- Features and deprecations must be submitted against branch 4.4.
- Legacy code removals go to the master branch.
-->
Commits
-------
fab17a4487 Improve some URLs
This PR was merged into the 3.4 branch.
Discussion
----------
[Debug][ExceptionHandler] Add tests for custom handlers
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
In https://github.com/symfony/symfony/pull/31694 I mixed many things but the whole PR was closed. I wrote some tests for custom handlers + the handle tests don't use mock anymore
I think they are useful even if the `ExceptionHandler` will disappear in the new component because it will still exists in 4.4 for the next 3 years.
Commits
-------
c53e25332a [Debug][ExceptionHandler] Add tests for custom handlers
This PR was merged into the 3.4 branch.
Discussion
----------
Remove dead tests fixtures
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
Once this is merged up to 4.2, I will check 4.2.
Commits
-------
f7e24c2c80 Remove dead tests fixtures
If the included file contains an error, it hides the real error. This
makes debugging harder.
How to reproduce:
```
composer create-project symfony/skeleton symfony-3.4 3.4
cd symfony-3.4
composer req monolog
```
Add to `monolog.yaml`:
```yaml
elasticsearch:
type: "elasticsearch"
elasticsearch:
host: 'elasticsearch'
port: '9200'
index: 'ep_php_logs_dev'
level: 'debug'
tags: 'monolog.logger'
channels: ['!event']
```
This will fail because the the \Elastica\Client class does not exist.
But this error will be hidden by the `ClassNotFoundFatalErrorHandler`
because it will try to load the `Symfony\Component\Kernel\Client` and
this class extends `Symfony\Component\BrowserKit\Client`. The last one
is a soft dependency...
---
Before
```
Fatal error: Uncaught Error: Class 'Symfony\Component\BrowserKit\Client' not found in /tmp/symfony-3.4/vendor/symfony/http-kernel/Client.php:31
```
After:
```
Fatal error: Uncaught Symfony\Component\Debug\Exception\ClassNotFoundException: Attempted to load class "Client" from namespace "Elastica".
Did you forget a "use" statement for another namespace? in /tmp/symfony-es/var/cache/dev/ContainerWXN4mS9/srcApp_KernelDevDebugContainer.php:303
```
Using "Foo", a class name that corresponds to no less than 22 fixture
classes, results in the first found "Foo" being loaded when one is
found by the ClassNotFoundFatalErrorHandler error handler, I am not sure
exactly why, but it is not really a big issue because this is a fatal
error handler and execution is not supposed to continue after that.
Except that is very much the case when running the whole test suite
sequentially with ./phpunit . Then we arrive to the DI component test
suite, and a failure happens because \\foo was not supposed to be defined:
> Failed asserting that exception message 'The definition for "\foo" has
> no class attribute, and appears to reference a class or interface in the
> global namespace. Leaving out the "class" attribute is only allowed for
> namespaced classes. Please specify the class attribute explicitly to get
> rid of this error.' contains 'The definition for "\foo" has no class.'.
This PR was merged into the 3.4 branch.
Discussion
----------
[Debug][ErrorHandler] Preserve our error handler when a logger sets another one
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
When logging errors handled by the `ErrorHandler::handleError()` method, the logger can temporarily set its own custom error handler. This is for example the case of `Monolog` in the `StreamHandler` class (cf ebb804e432/src/Monolog/Handler/StreamHandler.php (L101)).
However, when the previous error handler is restored by the logger, it "skips" the real previous handler (the `ErrorHandler::handleError()` one) in the pile and goes back directly to the one before. I guess this is because the `restore_error_handler()` call is technically done in the error handler itself, so it logically restore it to the one before and not to itself.
Here is an easy small example that shows the PHP behavior : https://3v4l.org/4OZNZ
The only solution I have found to fix it is to set our error handler everytime an error is logged.
Here are the things I discovered while trying to find a cleaner fix :
- Setting the same error handler in the error handler itself doesn't actually add it to the pile. This is why adding a check is useless.
- Checking if the logger modified the error handler is impossible anyway : to get the current error handler, you need to set a new one temporarirly and then revert it. However, when you revert it by calling `restore_error_handler()` you end up having the same problem you are trying to fix...
- Also trying to get the current error handler in the error handler itself will return NULL if it is itself.
Commits
-------
b979fff6b8 [Debug][ErrorHandler] Preserve our error handler when a logger set another one