framework: [5.1] [5.2] Error handler hides PHPUnit errors

I had the same issue. (Using Laravel 5.2) The problem was that i had a newer version of phpunit installed globally (5.4.4). So by running phpunit command the global one was used.

Solutions:

1. Use ./vendor/bin/phpunit instead;
2. Downgrade the global phpunit, after which you can use the phpunit command regularly.

composer global remove phpunit/phpunit
composer global require 'phpunit/phpunit=~4.0'

Or just don’t globally require PHPUnit.

Hope somebody finds this useful.

Ping @taylorotwell Merciful, God, what kind of begging/bribery/weeping will get this fixed? This issue has beet floating around for years now.Would setting up a Crowdfunder.com help???

Now I gotta go into work Wednesday and explain to my boss, who is not an open-source fan, why it took days to find a trivial error in my config file.

OK (36 tests, 2155 assertions)

Generating code coverage report in PHP format …PHP Fatal error: Uncaught Illuminate\Contracts\Container\BindingResolutionException: Target [Illuminate\Contracts\Debug\ExceptionHandler] is not instantiable. in /home/vagrant/repos/toto/vendor/laravel/framework/src/Illuminate/Container/Container.php:895 Stack trace: #0 /home/vagrant/repos/toto/vendor/laravel/framework/src/Illuminate/Container/Container.php(735): Illuminate\Container\Container->notInstantiable(‘Illuminate\Cont…’) #1 /home/vagrant/repos/toto/vendor/laravel/framework/src/Illuminate/Container/Container.php(608): Illuminate\Container\Container->build(‘Illuminate\Cont…’) #2 /home/vagrant/repos/toto/vendor/laravel/framework/src/Illuminate/Container/Container.php(575): Illuminate\Container\Container->resolve(‘Illuminate\Cont…’) #3 /home/vagrant/repos/toto/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(728): Illuminate\Container\Container->make(‘Illuminate\Cont…’) #4 /home/vagrant/repos/toto/vendor/laravel/framework/src/Illuminate/Foundation/Bootstrap/HandleExceptions.php(159): Illumin in /home/vagrant/repos/toto/vendor/laravel/framework/src/Illuminate/Container/Container.php on line 895 PHP Fatal error: Uncaught Illuminate\Contracts\Container\BindingResolutionException: Target [Illuminate\Contracts\Debug\ExceptionHandler] is not instantiable. in /home/vagrant/repos/toto/vendor/laravel/framework/src/Illuminate/Container/Container.php:895 Stack trace: #0 /home/vagrant/repos/toto/vendor/laravel/framework/src/Illuminate/Container/Container.php(735): Illuminate\Container\Container->notInstantiable(‘Illuminate\Cont…’) #1 /home/vagrant/repos/toto/vendor/laravel/framework/src/Illuminate/Container/Container.php(608): Illuminate\Container\Container->build(‘Illuminate\Cont…’) #2 /home/vagrant/repos/toto/vendor/laravel/framework/src/Illuminate/Container/Container.php(575): Illuminate\Container\Container->resolve(‘Illuminate\Cont…’) #3 /home/vagrant/repos/toto/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(728): Illuminate\Container\Container->make(‘Illuminate\Cont…’) #4 /home/vagrant/repos/toto/vendor/laravel/framework/src/Illuminate/Foundation/Bootstrap/HandleExceptions.php(159): Illumin in /home/vagrant/repos/toto/vendor/laravel/framework/src/Illuminate/Container/Container.php on line 895

@casperbakker oh the joys of development. Ironically for me changing processIsolation from true to false fixed it. Honestly.

Love beautiful code? Yea. I have nowhere near the skill, experience or access to internal documentation/procedures/architecture to even begin to start to address this or even explain what’s going on. What exactly in a container?? What’s a BindingResolution and why does it have a special exception. I dunno. I’m not asking for a major enhancement to be delivered tomorrow. I’m asking that a CLEARLY well documented (multiple times), two year old bug to be addressed within the next year (yea, I’d be happy with that). I’m just a poor sap that picked Laravel thinking that this type of bug would be addressed by the Laravel eco-system.

Changing processIsolation="false" to processIsolation="true" fixed this issue for me as well. Now I see the real error of the test.

PHPUnit 5.7.22 PHP 7.1.10 Laravel 5.4.36

No need for confirmations please. We know it’s broken. 😉

@jschlies I second what @iget-master said. None of the contributors to Laravel or to other open-source projects are being paid for their efforts. Nor do they owe you anything. It’s one thing to ask for help, but another to demand that they fix something for you, especially with the tone you used.

Tell your boss there’s a problem with a thing on the internet and the only way to fix it is to do some stuff. And if he doesn’t that, tell them they’re free to get the Oracle solution for $1 billion plus a lifetime support contract.

This is still a bug. Think it might help people out to at least reopen it so they know it’s still an unresolved problem. That exclude filter doesn’t fix.

mine wasn’t a syntax error, i install phpunit v5.* globally on my linux machine, so when i run phpunit it uses the default instead of the one with the project so, fixed my by running phpunit like this; vendor/bin/phpunit

@GrahamCampbell @taylorotwell can we re-open this? I’m also still seeing this issue. PHPUnit 6.0.13 by Sebastian Bergmann and contributors.

Runtime: PHP 7.1.3 with Xdebug 2.5.0 Configuration: /home/rof/src/bitbucket.org/waypointbuilding_team/toto/phpunit.ci.xml

…E

Time: 10.05 seconds, Memory: 14.00MB

There was 1 error:

1. App\Waypoint\Tests\Api\ClientAdmin\BomaClientCategoryApiTest::it_can_create_boma_client_categories PHPUnit\Framework\Exception: PHP Fatal error: Uncaught Illuminate\Contracts\Container\BindingResolutionException: Target [Illuminate\Contracts\Debug\ExceptionHandler] is not instantiable. in /home/rof/src/bitbucket.org/waypointbuilding_team/toto/vendor/laravel/framework/src/Illuminate/Container/Container.php:873 Stack trace: #0 /home/rof/src/bitbucket.org/waypointbuilding_team/toto/vendor/laravel/framework/src/Illuminate/Container/Container.php(725): Illuminate\Container\Container->notInstantiable(‘Illuminate\Cont…’) #1 /home/rof/src/bitbucket.org/waypointbuilding_team/toto/vendor/laravel/framework/src/Illuminate/Container/Container.php(598): Illuminate\Container\Container->build(‘Illuminate\Cont…’) #2 /home/rof/src/bitbucket.org/waypointbuilding_team/toto/vendor/laravel/framework/src/Illuminate/Container/Container.php(567): Illuminate\Container\Container->resolve(‘Illuminate\Cont…’) #3 /home/rof/src/bitbucket.org/waypointbuilding_team/toto/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(708): Illuminate\Container\Container->m in /home/rof/src/bitbucket.org/waypointbuilding_team/toto/vendor/laravel/framework/src/Illuminate/Container/Container.php on line 873 PHP Fatal error: Uncaught Illuminate\Contracts\Container\BindingResolutionException: Target [Illuminate\Contracts\Debug\ExceptionHandler] is not instantiable. in /home/rof/src/bitbucket.org/waypointbuilding_team/toto/vendor/laravel/framework/src/Illuminate/Container/Container.php:873 Stack trace: #0 /home/rof/src/bitbucket.org/waypointbuilding_team/toto/vendor/laravel/framework/src/Illuminate/Container/Container.php(725): Illuminate\Container\Container->notInstantiable(‘Illuminate\Cont…’) #1 /home/rof/src/bitbucket.org/waypointbuilding_team/toto/vendor/laravel/framework/src/Illuminate/Container/Container.php(598): Illuminate\Container\Container->build(‘Illuminate\Cont…’) #2 /home/rof/src/bitbucket.org/waypointbuilding_team/toto/vendor/laravel/framework/src/Illuminate/Container/Container.php(567): Illuminate\Container\Container->resolve(‘Illuminate\Cont…’) #3 /home/rof/src/bitbucket.org/waypointbuilding_team/toto/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(708): Illuminate\Container\Container->m in /home/rof/src/bitbucket.org/waypointbuilding_team/toto/vendor/laravel/framework/src/Illuminate/Container/Container.php on line 873

ERRORS! Tests: 12, Assertions: 237, Errors: 1.

i started getting this when i am using a new vps for gitlab runner running php artisan dusk

hope someone will find fix for it.

and as some more people facing issue, isn’t time to make issue “open” ?

thanks.

Hi, I’m running:

Laravel Framework 5.5.25
PHP 7.2.0-1+ubuntu16.04.1+deb.sury.org+1
Zend Engine v3.2.0
    with Zend OPcache v7.2.0-1+ubuntu16.04.1+deb.sury.org+1
    with Xdebug v2.6.0beta2-dev
    with blackfire v1.18.0~linux-x64-non_zts72

and it throws an exception when creating code coverage report

PHP Fatal error:  Uncaught Illuminate\Contracts\Container\BindingResolutionException: Target [Illuminate\Contracts\Debug\ExceptionHandler] is not instantiable. in /home/vagrant/ApoiadorDigital/api.apoiadordigital.com.br/vendor/laravel/framework/src/Illuminate/Container/Container.php:918

any suggestions?

I’m on php7.2 and laravel 5.7 now and it’s still happening.

possibly related, chrome driver has this output:

$ ~/chromedriver-linux 
Starting ChromeDriver 2.35.528139 (47ead77cb35ad2a9a83248b292151462a66cd881) on port 9515
Only local connections are allowed.



[1548345398.028][SEVERE]: Timed out receiving message from renderer: 300.000
[1548345398.030][SEVERE]: Timed out receiving message from renderer: -0.002
[1548345698.035][SEVERE]: Timed out receiving message from renderer: 300.000
[1548345698.037][SEVERE]: Timed out receiving message from renderer: -0.002
[1548348592.400][SEVERE]: Timed out receiving message from renderer: 300.000
[1548348592.403][SEVERE]: Timed out receiving message from renderer: -0.003
[1548348892.409][SEVERE]: Timed out receiving message from renderer: 300.000
[1548348892.411][SEVERE]: Timed out receiving message from renderer: -0.002
[1548352791.671][SEVERE]: Timed out receiving message from renderer: 300.000
[1548352791.673][SEVERE]: Timed out receiving message from renderer: -0.002
[1548353091.676][SEVERE]: Timed out receiving message from renderer: 300.000
[1548353091.683][SEVERE]: Timed out receiving message from renderer: -0.007

Same issue, phpunit errors not showing, changing the processIsolation doesn’t change anything either.

PHP Fatal error:  Uncaught Illuminate\Contracts\Container\BindingResolutionException: Target [Illuminate\Contracts\Debug\ExceptionHandler] is not instantiable. in /var/www/lbv/vendor/laravel/framework/src/Illuminate/Container/Container.php:918

Vagrant environment: PHPUnit 6.4.2 PHP 7.1 Laravel 5.5.16

Just to add my fix in case it helps anyone:

Laravel 5.1.45 PHPUnit 4.8.35 PHP 5.5.9 Xdebug 2.2.3

I stepped through PHP_CodeCoverage to find that an exception was being thrown in getData() on the call to addUncoveredFilesFromWhitelist(). A twitter exchange from @s_bergmann suggests:

@user1: In @phpunit, what’s the difference between addUncoveredFilesFromWhitelist="true" and processUncoveredFilesFromWhitelist="true" ? @s_bergmann: You want to use processUncoveredFilesFromWhitelist. If it does not work (legacy code) then use addUncoveredFilesFromWhitelist

(from http://stackoverflow.com/questions/29041254/phpunit-coverage-what-is-the-difference-between-adduncoveredfilesfromwhitelist)

So changing phpunit.xml from:

<whitelist processUncoveredFilesFromWhitelist="true">

to:

<whitelist addUncoveredFilesFromWhitelist="true">

And I’ve got code coverage back with no exception. Not totally sure what I’ve lost, but the end result looks complete to me.

Mine was different phpunit in the system and the application. Removed one from system and updated composer.json to "phpunit/phpunit": "5.*",

Now it runs fine. 😃

Hi, I have tried

composer global remove phpunit/phpunit
sudo apt-get purge phpunit

and ./vendor/bin/phpunit works

Laravel Framework version 5.2.44 PHP 7.0.8-0ubuntu0.16.04.2 PHPUnit 4.8.27

See https://github.com/laravel/laravel/pull/3725.

Thanks everyone. Debugging this with @bretterer, we can see that phpunit is requiring the routes file, which has consequences.

This was happening for me, and it ended up being a permissions problem.

I got the same issue.

I try to catch exception when TestRunner is generating coverage

/vendor/phpunit/phpunit/src/TextUI/TestRunner.php

$this->printer->write(
    "\nGenerating code coverage report in HTML format ..."
);

try {
    $writer = new PHP_CodeCoverage_Report_HTML(
        $arguments['reportLowUpperBound'],
        $arguments['reportHighLowerBound'],
        sprintf(
            ' and <a href="https://phpunit.de/">PHPUnit %s</a>',
            PHPUnit_Runner_Version::id()
        )
    );

    $writer->process($codeCoverage, $arguments['coverageHtml']);

    $this->printer->write(" done\n");
    unset($writer);
} catch (PHP_CodeCoverage_Exception $e) {
    $this->printer->write(
        " failed\n" . $e->getMessage() . "\n"
     );
} catch (Exception $e) {
    dd($e);
}

and got error message:

Could not write to coverage/index.html: failed to open stream: Permission denied

After change coverage directory permission to 755 from 555, It’s work.

Hope helpful.

PHP: 5.6.25 Laravel: 5.2 PHPUnit:4.8.36 Xdebug: 2.5.5

@jschlies

Get with the flow of things or don’t use the free software at all. Why are you feeling so entitled that a bug needs to be addressed in the next year or even the next 10 years when you’re using what they develop for free?

There’s documentation for the api, framework and you can just read the source code itself to see how everything works. Not everyone who contributes back to the framework knows how every single part of the framework works.

Does the bug affect you? yes? Is the bug a major breaking problem? yes? no? Make a report, wait for it to be fixed. Can’t wait for it? Fix it yourself or use a different framework. Your tone in your posts are really way off, expecting people to fix things for you.

@jschlies you are free to fix the problem and submit a pull request, also you can contribute with the laravel framework before come here with ironies…

As a followup. I found that adding

/**
 * @preserveGlobalState disabled
 */

to DuskTestCase works as well, but has WAY better performance than enabling processIsolation.

If changing processIsolation=false don’t work, you can try with this solution:

$app->singleton(
    Illuminate\Contracts\Debug\ExceptionHandler,
    DummyApp\Exceptions\Handler
);

Another problem can be a library for PHPUnit, on my case, was codedungeon/phpunit-result-printer 0.25.*

I got the problem when an exception was thrown in tearDownAfterClass.

Windows 10 x64 PHP 7.0.15-nts-x64 PHPUnit 4.8.16 Laravel 5.1.23

I have the same issue with: PHPUnit 6.4.1 PHP 7.1.3 Laravel 5.5.14 Homestead 2.1.0

In my case, I want to test for SoapFault errors. I have an instance of a SoapClient with an invalid WSDL URI:

try {
    $client = new \SoapClient('http://example.com/invalid/wsdl', ['exceptions' => true]);
    $client->foo('bar');
} catch (SoapFault $e) {
    // the exception is being caught and reported successfully
    // SOAP-ERROR: Parsing WSDL: Couldn't load from ...
    report($e);
}

However, the SoapClient raises a E_ERROR even with the 'exceptions' => true option. This is probably a bug in PHP, but the issue here is how that error is handled by Laravel.

Upon inspection, here are the steps in chronological order:

1. The test execution starts.
2. The SoapClient raises a SoapFault exception, which is being caught and reported as intended.
3. The SoapClient raises an error (E_ERROR), which is displayed on the console output, with the same message as the exception.
4. The test is green, and the assertions are passing.
5. The tearDown method of Illuminate\Foundation\Testing\TestCase is being invoked.
6. App@flush()is called, which also calls Container@flush.
7. The bindings and instances of the container are emptied. As a result, the application’s exception handler and the binding for the Illuminate\Contracts\Debug\ExceptionHandler::class are gone. This is important.
8. After PHPUnit exits (succesfully), PHP’s register_shutdown_function is called, and it invokes Illuminate\Foundation\Bootstrap\HandleExceptions@handleShutdown.
9. Now Laravel is checking for a error_get_last(), and will handle any fatal error.
10. Since the SoapClient generated an E_ERROR, it will be now converted to a FatalErrorException and passed to HandleExceptions@handleException.
11. At this point there is a try/catch statement which attempts to report the exception. This will call getExceptionHandler, which resolves the exception handler contract from the container. But since step 7, there is no exception handler, so the container throws a BindingResolutionException.
12. The catch statement does nothing, and the script continues to call renderForConsole, which again tries to get the exception handler from the container. There is no try/catch there, so this is why everyone is seeing a BindingResolutionException error.
13. The BindingResolutionException is being handled in the handleException method because of the set_exception_handler, which makes the steps 11-12 to recur. That’s why the exception is shown twice on the console.

IMO, Laravel maybe Laravel should try to handle unhandled errors (get_last_error), before the application is flushed. We have beforeApplicationDestroyedCallbacks being called just before flushing, so maybe somewhere in the setUp we should register a callback to handle those errors before shutdown.