BindingResolutionException with ExceptionHandler #6322
Comments
|
Looks like we need to register our own ExceptionHandler (in our own ErrorServiceProvider) now. Would be great if something like this could be documented. Also, as default behavior (if it's not a bug but rather an intended feature) this is very end-use unfriendly. |
|
Which means what if you could tell me exactly what to do? :p |
|
What I did is the following (no idea at all if this is OK or best practice or if it even works): Added an ErrorServiceProvider to App\Providers: <?php namespace App\Providers;
use Illuminate\Support\ServiceProvider;
use Whoops\Handler\PrettyPageHandler;
use Whoops\Run;
class ErrorServiceProvider extends ServiceProvider {
/**
* Register any error handlers.
*
* @return void
*/
public function boot() {
// This is only if you use the Whoops error handler (install via composer).
/*$whoops = new Run;
$whoops->pushHandler( new PrettyPageHandler );
$whoops->register();*/
}
/**
* Register the service provider.
*
* @return void
*/
public function register() {
$this->app->bind( 'Illuminate\Contracts\Debug\ExceptionHandler', 'App\Library\Exception\ExceptionHandler' );
}
}Added an ExceptionHandler to App\Library\Exception: <?php
namespace App\Library\Exception;
use Exception;
use Illuminate\Contracts\Debug\ExceptionHandler as ExceptionHandlerContract;
use Illuminate\Http\Response;
class ExceptionHandler implements ExceptionHandlerContract {
protected $handlers = array();
/**
* Report or log an exception.
*
* @param \Exception $e
*
* @return void
*/
public function report( Exception $e ) {
}
/**
* Render an exception into an HTTP response.
*
* @param \Illuminate\Http\Request $request
* @param \Exception $e
*
* @return \Symfony\Component\HttpFoundation\Response
*/
public function render( $request, Exception $e ) {
return new Response( $e->getMessage(), 500 );
}
/**
* Render an exception to the console.
*
* @param \Symfony\Component\Console\Output\OutputInterface $output
* @param \Exception $e
*
* @return void
*/
public function renderForConsole( $output, Exception $e ) {
echo $e->getMessage();
}
}And then I registered my service provider in |
|
Ixx... very ugly problem! My app is down too... |
|
I may have hit the same error as my error message looks pretty similar. I got this while trying to add HTML class to L5, but obviously the error is absolutely not related to HTML service provider. I installed XDebug and dig into the code, my current assumption is that the exception handler that is suppose to write something intelligent on the console/log fails and the error we get, comes from an error in the exception handler itself In my case, in order to debug my HTML::xxx I added and brutal "$a= new HtmlBuilder(); error_log(sprintf("****** a=%s", $a));" which created a new error as in PHP object cannot be printed as string directly. But while I should have got something: Tracing with the XDebug, I find out that if 1st handler collects correctly the error message "file Kernel.php:37" the next one "HandleExceptions.php:73, Illuminate\Foundation\Bootstrap\HandleExceptions->handleException()" never returns from GetExpectionHandler()->report method. I try to trace deeper, but got lost :( Reproducing the bug should be simple. In a controller do something stupid like I did [converting an object in String], this will raise an exception and as today it fail with "[Illuminate\Contracts\Debug\ExceptionHandler] is not instantiate" with an error in the core of L5 when it should not. |
|
You're doing it wrong. |
|
Example of the right way to do this: Bind your exception handler here: https://github.com/GrahamCampbell/Bootstrap-CMS/blob/c09201d361921b985d99727c64cd444ef51afc1c/bootstrap/app.php#L51. Write your exception hander: https://github.com/GrahamCampbell/Bootstrap-CMS/blob/c09201d361921b985d99727c64cd444ef51afc1c/app/Debug/ExceptionHandler.php. In this case, I've abstracted the juicy bits for my debug displayer, and my own plain displayer to separate classes: https://github.com/GrahamCampbell/Bootstrap-CMS/blob/c09201d361921b985d99727c64cd444ef51afc1c/app/Debug/DebugDisplayer.php, https://github.com/GrahamCampbell/Bootstrap-CMS/blob/c09201d361921b985d99727c64cd444ef51afc1c/app/Debug/PlainDisplayer.php. My example actually uses whoops too, so it should suite you. You may want to simply return the symfony plain error response instead of what I've done. |
|
Thank you GrahamCampbell the lack of binding in bootstrap was the error was. When I downloaded L5 few days ago the exception handler binding was missing from bootstrap/app.php and unfortunately composer update does not warn you about it app.php when you try to update. Might be a good idea to shift to git for all those L5 test. The bad news is that I lost 1/2 day tracking a no existing bug. The good new is that I now have a XDebug in place with PhpStorm and that's really cool. |
|
@GrahamCampbell very nice, thank you. Closing the issue with "You're doing it wrong." though -- thats's rather arrogant. When we cloned the l5 dev version, the IoC binding for If you're not intimately familiar with a framework (or an updated version of a framework), the solution is not -- at first glance -- visible. Thanks for posting your solution though. Abstracting out the displayer is a nice idea and I will do a similar approach. |
|
@darkwinternight My "arrogant" comment was as it was because the laravel issues aren't meant for discussion of how to do things - they're meant for discussion of bugs (and new features). This is something more for the forums. My comment was meant to close this up quickly. When using Laravel 5, you're going to have to follow the changes in laravel/framework and laravel/laravel very closely, as am I. Taylor is the one making the big changes and making the decisions. |
|
@GrahamCampbell good talk! Like every day I setup a fresh new test project from laravel and diff the app files... |
|
It is through that Graham answer was a little raw :) For me two lines missing in a config file should be conciser as a bug. I agree that it's an normal bug in a beta live cycle, but it's still a bug. This being said, Graham provided me with the answer. A the end of the day, this is what was really important to me. |
|
@fulup-bzh And to me :) Thanks again @GrahamCampbell. |
|
In Ubuntu Client this is the app I use to see the diff between dev releases: https://apps.ubuntu.com/cat/applications/raring/meld/ |
|
They are many good tools for compare/diff. The most impressive one I used being Netbeans. I'm in the process of moving from NB to PhpStorm but diff/history is one area where NB really out perform anyone else. |
|
Laravel 5 has been released to the masses and I am leading a conversion from Slim / Eloquent 4 to Laravel 5. However, I am seeing this exception being thrown and rethrown as I'm implementing tests to debug the code that we are moving over. Is there anything in the works to provide some default handling around this so that it works out of the box? Can anyone help me (new to Laravel not php or phpunit) and others who are not experienced with Laravel to know how to quickly overcome this error in Unit Tests and elsewhere so that we're not getting hit with it every time there is an exception thrown? |
|
^^^^ +1 |
|
+1 |
|
I encountered this problem when running tests with phpunit in laravel 5.0 and seems to be specific to laravel + phpunit. It works because Anyway, this only happens in 5.0 and not in 5.1 (as far as a I can tell) |
|
Had the same problem the other day. Apparently the default Handler shipped with L5.2 has to be combined with the ExceptionHandler interface: |
|
Note to others who happen to land here: check your phpunit version, L5.2 supports phpunit 4.8 |
|
I'm running into error This happen on a fresh homestead 3.3 box. PHP 5.6.15. |
|
Yup, So strange, I got this with Laravel 5.1 . Quite confusing |
|
The issue for me was that I had a custom |
|
I'm getting this issue when i run phpunit tests on circle-ci, the odd part is if i ssh to the circle-ci box myself and run @GrahamCampbell i don't know why this hasn't been re-opened, this is a pretty severe issue and obviously not fixed, there are several issues on this that when even closed people are still commenting they are engaging |
|
My bad, I forgot to call parent::setUp() on a TestCase, so all test setup was not being initialized. Maybe it helps someone. |
|
@GrahamCampbell @taylorotwell I once again am strongly suggesting we re-open these issues, whatever is the particular problem people are having or if they're "doing it wrong" is not the issue here. Look at everyones comments on their fixes and how there is barely any relation to the error. The issue is the handler not properly finding/tracking/displaying what actually is going on. This is by far one of the most Achilles' Heel's types of bugs for any framework, and generally scares me that I have it running on production. |
|
@acidjazz how do I recreate it on a fresh installation of Laravel? |
|
@taylorotwell that is the current ultimate question, especially in my particular issue where connecting to the machine and trying to debug this makes it disappear, still no consistent success. I'll do what I can to help, ill start scouring other issues like and maybe even |
|
I came across this error when running L5.2 with the 'lowest' flag on Travis, using PHPUnit |
|
@barryvdh interesting, I'm starting to guess this is somewhat related to a "headless server" type issue where something potentially is lacking or running that is needed to properly error. |
|
As stated above @GrahamCampbell i don't know why this hasn't been re-opened, this is a pretty severe issue and obviously not fixed, there are several issues on this that when even closed people are still commenting they are engaging. To my untrained eyes, this issue has been floating around for years. Sorry if I'm being spam-my. I'm unsure where to post this. PHPUnit 6.0.13 by Sebastian Bergmann and contributors. Runtime: PHP 7.1.3 with Xdebug 2.5.0 ...........E Time: 10.05 seconds, Memory: 14.00MB There was 1 error:
ERRORS! |
|
@jschlies I have this problem too with next ant config: <exec executable="${phpunit}" resultproperty="result.phpunit" taskname="phpunit">
<arg value="--coverage-clover"/>
<arg path="${basedir}/build/coverage"/>
</exec>And I have not this problem with next ant config (html instead of clover): <exec executable="${phpunit}" resultproperty="result.phpunit" taskname="phpunit">
<arg value="--coverage-html"/>
<arg path="${basedir}/build/coverage"/>
</exec>Are anybody knows reason? |
|
I encountered this issue when running phpunit tests. I turned off processIsolation in phpunit.xml and the issue resolved. Not sure why.... |
|
The solution is to upgrade your PHP to PHP 7 or later. I encountered this same issue and I resolved by upgrading to PHP 7.1 |
|
Cool. We're at 7.1. I'll try to recreate ad let you know. |
|
@mnvx - I am having this same issue. Currently running the following:
Issue only occurs when using the |
|
Under php 7.1, I'm unable to recreate. "laravel/framework": "5.4.*", vagrant@homestead: vagrant@homestead:~/repos/toto$ phpunit -version |
|
My problem was with "codedungeon/phpunit-result-printer 0.20.1", downgrade library to 0.19.* fix the problem. |
Confirming the same issue here. Downgrading to 0.19.* resolved the issue. Did some further digging, and this issue seems to be caused by a configuration flag in the options:
cd-printer-hide-class: false
cd-printer-simple-output: false
cd-printer-show-config: true
cd-printer-hide-namespace: false
cd-printer-anybar: false
cd-printer-anybar-port: 1738
markers:
cd-pass: "✓ "
cd-fail: "✖ "
cd-error: "⚈ "
cd-skipped: "→ "
cd-incomplete: "∅ "
cd-risky: "⌽ "
` |
|
In the Laravel 8.* Fresh Setup updated RouteServiceProvider and it affects route with string syntax. |
|
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. |
|
I'm surprised nothing has been done about this for 10 years, and yes, I've been experiencing this issue on/off for that long, but anyways here is a new discovery that hopefully leads to someone else fixing this bug. I made this change: + try {
Assert::assertEquals($expected, $actual, 'message');
+ } catch (\Throwable $e) {
+ dump([
+ '$expected' => $expected,
+ '$actual' => $actual,
+ ]);
+ // if I don't wrap this, I get BindingResolutionException
+ throw new \Exception($e->getMessage(), 0, $e);
+ }This leads to my expected Exception stack being thrown in addition to the "Caused by PHPUnit\Framework\ExpectationFailedException" stack under it. It's not desired to replace phpunit's assertions with an exception, but there's no explanation for why here and only here assertions cause The main issue with the |
and others
It looks like the ExceptionHandler has a problem with PHP Fatal Errors. I simply get a blank page and this shows up in the log:
The text was updated successfully, but these errors were encountered: