PHP Fatal error: Uncaught Illuminate\Contracts\Container\BindingResolutionException: Target [Illuminate\Contracts\Debug\ExceptionHandler] is not instantiable. in /app/vendor/laravel/framework/src/Illuminate/Container/Container.php:958 #28809
Comments
|
Have you tried |
yes. i read that from some other thread/issue whilst in this google rabbit hole. it still doesn't work. |
|
Have you tried removing the package? Unfortunately this GitHub area is not a support area for general application issues. This is only for issues/bugs with the framework code itself. I will be closing your ticket here. Instead please try asking your question on one of the many great community support areas that will likely give you a better answer more quickly:
If you feel I've closed this issue in error, please provide more information about how this is a framework issue, and I'll reopen the ticket. Thanks in advance. |
|
duplicate: #10808 |
|
For me it turned out to be access rights. This might be an issue for vm/container environments. |
|
@aysegeertsma - can you elaborate on the vm/container environments comment? We are experiencing something similar and aren't sure how to fix it. |
I've figured out the solution for this problem. It's been solved by setting |
|
Adding |
|
In my case the issue was caused by a psr-0 autoload definition for Facebook SDK 3.2.2 in a legacy app that's running L8 in parallel with ZF1. Definitions are correct in autoload_classmap. It doesn't occur on our servers nor dev workstation only in our GitHub Action which is getting this error when running pest. The unit tests complete and the error occurs soon as the coverage begins in the GIthub Action. For the fix we removed any access to the legacy psr-0 Facebook sdk from the Laravel side and rewrote using Facebook's modern php-graph-sdk. Our legacy unit tests for ZF1 still work properly using the psr-0 version. |
|
Try to delete vendor folder and run "composer install" again. should be fixed |
|
For me, it was simply caused by a mismatch between the name of a PHP file and the name of its class. Fixing it then doing a "composer dump-autoload" fixed the problem. |
|
For me it was the |
I think enough people have encountered this consistently since 2015 to consider this a confirmed framework bug. The only thing that's not clear is if the bug is in laravel or phpunit. |
|
@carcinocron Only if you can create a reproducible result of the bug where it's clear for the maintainers to investigate. 😉 |
|
in my case I used |
|
This just started happening to me today, but only happens when I run with paratest I will note, when I run with |
|
To add, in my situation I updated to phpunit 10.5.33 and the issue is now resolved. |
|
I have a Laravel 10 project that recently started giving the Uncaught error in Container after parallel tests. I tried setting to 10.5 in the composer.json but am still seeing lower versions in the composer.lock file probably because of some dependencies. I can confirm that without using --parallel the tests run fine. This seems like a minor annoyance but still something that it would be nice to get fixed. PHP Fatal error: Uncaught Illuminate\Contracts\Container\BindingResolutionException: Target [Illuminate\Contracts\Debug\ExceptionHandler] is not instantiable. in /var/www/html/vendor/laravel/framework/src/Illuminate/Container/Container.php:1126 |
|
I had an old phpunit.xml file since this project has been around for a while. I went ahead and updated the phpunit.xml to merge in things like processIsolation from https://github.com/laravel/framework/blob/10.x/phpunit.xml.dist, re-ran composer dump-autoload and re-ran the test and am still seeing the issue. |
|
I got the same error after switching to PHP 8.3. For me, the problem was gone after doing a |
|
For me, running the composer update resolved the issue on localhost; however, the error continues to occur in the GitLab CI/CD. |
|
This solved it in my case: #890. |
|
The immediately visible "target ExceptionHandler is not instantiable" exception comes from an ExceptionHandler instance not being DI'd into the application. Not sure what circumstances this can happen under, but it creates a chicken/egg problem. The scenario I see this under is trying to run ex. Easiest solution AFAICT is to create register a custom exception handler class for your application. (I'm new to Laravel so I apologize if there's a better way of doing this that I missed :') In use Illuminate\Contracts\Debug\ExceptionHandler;
use Symfony\Component\HttpFoundation\Response;
class MyHandler implements ExceptionHandler {
function report(Throwable $e) { /* just rendering as response or to console is enough */ }
function shouldReport(Throwable $e) { return true; }
function render($request, Throwable $e): Response { return response()->make("<pre>" . ((string) $e) . "</pre>", 500, ["Content-Type" => "text/html"]); }
function renderForConsole($output, Throwable $e) { error_log(((string) $e)); }
};
$app = Application::configure(basePath: dirname(__DIR__))
//
->create();
$app->singleton(ExceptionHandler::class, function (Application $app) {return new MyHandler;}); // <-- IMPORTANT
return $app;Now artisan again works as expected, and I also get error output in the HTTP response when endpoints throw exceptions. |
likely a duplicate of: #26874, but it was close 6 months ago. but there have been a few comments in the last month or so. perhaps others, like me are getting an issue still.
Description:
i'm getting this error (after adding https://github.com/sebastiaanluca/laravel-auto-morph-map via composer). when i run phpunit i get a few fatal errors. not sure how/why the package would have messed it up. so any help would be great!
The text was updated successfully, but these errors were encountered: