Reading from non-existent file `test-results` in cache folder

[cracksalad]

Q	A
PHPUnit version	10.5.13 and 10.5.14
PHP version	8.1.26, 8.2.13, 8.3.0
Installation Method	PHAR (phive)

Summary

Best description is probably the exception itself:

PHPUnit 10.5.13 by Sebastian Bergmann and contributors.
Runtime:       PHP 8.3.0 with Xdebug 3.3.0
Configuration: /builds/x/y/phpunit.xml
An error occurred inside PHPUnit.
Message:  file_get_contents(/builds/x/y/.phpunit.cache/test-results): Failed to open stream: No such file or directory
Location: phar:///builds/x/y/tools/phpunit/phpunit/Runner/ResultCache/DefaultResultCache.php:78
#0 phar:///builds/x/y/tools/phpunit/phpunit/Runner/ResultCache/DefaultResultCache.php(78): file_get_contents('/builds/x/y...')
#1 phar:///builds/x/y/tools/phpunit/phpunit/TextUI/TestRunner.php(37): PHPUnit\Runner\ResultCache\DefaultResultCache->load()
#2 phar:///builds/x/y/tools/phpunit/phpunit/TextUI/Application.php(146): PHPUnit\TextUI\TestRunner->run(Object(PHPUnit\TextUI\Configuration\Configuration), Object(PHPUnit\Runner\ResultCache\DefaultResultCache), Object(PHPUnit\Framework\TestSuite))
#3 /builds/x/y/tools/phpunit(3002): PHPUnit\TextUI\Application->run(Array)
#4 {main}

Although this snippet shows the result with PHP 8.3.0 and PHPUnit 10.5.13, the same problem is observed using the version combinations stated above.

Current behavior

See Summary

How to reproduce

1. Delete your .phpunit.cache folder
2. Run PHPUnit

The cache folder does not exist in CI pipelines e.g. in GitLab (at least if you do not push it to your repo).

Expected behavior

I guess there should be a check, if the file exists before reading it. The problem could also be, that the file should have been created before it is read.

Additional Information

PHPUnit 10.5.10 and 10.5.12 work fine. I did not test other versions yet.

[Sebastian Bergmann]

This is likely caused by @staabm's change in #5742. It was previously reported by @Yurunsoft in #5742 (comment).

@cracksalad Are you using a custom error handler that is too eager, eg. handles issues that it is not responsible for?

[cracksalad]

@cracksalad Are you using a custom error handler that is too eager, eg. handles issues that it is not responsible for?

Yes, I am using a pretty typical Error to ErrorException converter which does not filter, if it is responsible for the source of the Error. It looks pretty much like this:

set_error_handler(function(int $err_lvl, string $err_msg, string $err_file, int $err_line): bool {
    throw new \ErrorException($err_msg, 0, $err_lvl, $err_file, $err_line);
});

[Sebastian Bergmann]

It is bad practice to handle errors that are not your own, more so when they are suppressed.

[Markus Staab]

yeah I agree. this error handler is bogus and is missing the logic to ignore lines which are prefixed with @.

the manual describes how to do it right https://www.php.net/manual/en/function.set-error-handler.php#refsect1-function.set-error-handler-examples

let me make the initial patch a bit more forgiving