When under production mode, if there is an error occurs in like say config/app.php, anything, just type an "ServiceProvider" that doesn't exists to test the error:

• it result that this page only display blank page with 500 error, and when i try catch parent::render($request, $e) the error is that "Class view does not exist"

However, for errors that occur in Controllers, Middlewares, are able to produce 500 Internal Server Error that this package provided.

Hope you know what I am mentioning about....

There is an issue with new laravel 5.3 apps.

The new auth middleware Illuminate\Auth\Middleware\Authenticate throws an AuthenticationException when the user is not logged in. The default exception handler handles this by calling the unauthenticated method in the App\Exceptions\Handler.

https://github.com/laravel/framework/blob/5.3/src/Illuminate/Foundation/Exceptions/Handler.php#L135

Currently the GrahamCampbell\Exceptions\NewExceptionHandler does not handle this Exception in any particular way and ends up displaying the whoops page.

I made an example repo for reference: https://github.com/scrubmx/issue-example/commits/master

I was getting a "Illuminate\Contracts\Container\BindingResolutionException: Target [Illuminate\Contracts\Debug\ExceptionHandler] is not instantiable" error while running phpUnit under Laravel 5.2 and managed to replicate it on a new project with just Laravel-Exceptions. I tracked it down to possible a missing comment in the installation documentation. It seems that, atleast on 5.2, you need to change the following in bootstrap\app.php

$app->singleton( Illuminate\Foundation\Exceptions\Handler::class, App\Exceptions\Handler::class );

to

$app->singleton( GrahamCampbell\Exceptions\ExceptionHandler::class, App\Exceptions\Handler::class );

Does that seem right? And if so, could you please add it to the installation description to help others?

Funny enough the site worked fine, just the phpUnit that was complaining about it.

So I'm finding that this package is causing a bit of grief with the exceptions.

Let's say I make an API request to get a resource, but my app denies the request through laravels ACL, this throws a AuthorizationException which does not implement the HttpExceptionInterface Interface.

Laravel doesn't add a code to this exception(it really should be a 401 or 403) so I wrote a transformer that returns the exception but with a 401 code.

The issue is that because it doesn't implement HttpExceptionInterface when this package uses Symfony's FlattenException the status code gets reset to 500 which is annoying, but manageable.

The real issue then comes in when we hit ExceptionInfo::generate because again we don't Implement HttpExceptionInterface we end up with the generic information from the json file.

So by the time the user get's the error they see

So basic question, why are we so reliant on HttpExceptionInterface?

Installed Laravel-Exceptions with Whoops on a project. Threw an exception to test and was surprised to be greeted by a generic server-generated 500 error page instead of whoops. My apache logs (using MAMP) indicated that duplicate 'Content-Type' were causing an error. I inspected the response return by the GrahamCampbell\Exceptions\ExceptionHandler::render() method and noticed that it specified Content-Type: text/html where as Illuminate's handler did not.

I'm not sure where the content type is being inserted after the Handler does its thing, but this duplicate is clearly causing an issue. I was able to remedy the situation by doing the following, but a more permanent fix might be better.

public function render($request, Exception $e)
{
    if ($e instanceof ModelNotFoundException) {
        $e = new NotFoundHttpException($e->getMessage(), $e);
    }
    $response = parent::render($request, $e);
    $response->headers->remove('Content-Type');
    return $response;
}

After installing this package, our 404, 500, 503, etc pages are gone. All we get is a white page.

In bootstrap/app.php this is how I call your exceptionhandler

$app->singleton(
    'Illuminate\Contracts\Debug\ExceptionHandler',
    'GrahamCampbell\Exceptions\ExceptionHandler' // before: App\Exceptions\Handler.
);

If I change the ExceptionHandler to use the native App\Exceptions\Handler error pages are shown just fine. Therefore it must be something to do with your package.

If debugmode is true I see default Whoops page. If debug mode is false I see white pages.

I am using bugsnag for my applications which means my handler.php is extending "Bugsnag\BugsnagLaravel\BugsnagExceptionHandler".

How can I use this package with bugsnag?

We should generate unique error codes and attach them to the logs, and present them to the user. That way if a user wants to contact support, they can provide us with the unique error code.

Laravel 5.4 & Whoops

When using Laravel's Illuminate\Foundation\Exceptions\Handler and visiting a protected route with auth middleware, the browser is redirected to a login page. (expected behaviour)

When using GrahamCampbell\Exceptions\NewExceptionHandler an AuthenticationException is rendered and not redirected to login page. (unexpected behaviour)

Looking at Laravel handler there is a check for AuthenticationException and the function unauthenticated is called

I couldn't find something similar on ExceptionHandlerTrait

The solution is to change the render function on App\Exceptions\Handler to take this into account

    public function render($request, Exception $exception)
    {
		if ($exception instanceof \Illuminate\Auth\AuthenticationException){
			return $this->unauthenticated($request, $exception);
		}
                return parent::render($request, $exception);
    }

I would really like to see custom displayers and the ability to customize the existing ones. My idea is to create a configuration file with all displayers that should be loaded as well as a default one. The configuration file would look something like to this:

/*
|--------------------------------------------------------------------------
| Default Exception Displayer
|--------------------------------------------------------------------------
|
| Here you may specify which of the exception displayers below you wish to
| use as your default displayer for all exceptions.
|
*/

'default' => 'plain',

/*
|--------------------------------------------------------------------------
| Exception Displayers
|--------------------------------------------------------------------------
|
| Here are each of the exception displayers setup for your application.
| Default displayers has been included, but you may add as many displayers
| as you would like.
|
*/

'displayers' => [
    'array' => 'GrahamCampbell\Exceptions\Displayers\ArrayDisplayer',
    'debug' => 'GrahamCampbell\Exceptions\Displayers\DebugDisplayer',
    'plain' => 'GrahamCampbell\Exceptions\Displayers\PlainDisplayer',
],

Each displayer class should have a class that we can call to determine if this displayer should be used or not. Currently named it use, there probably is a much better name.

/**
 * This is the array displayer class.
 *
 * @author Graham Campbell <[email protected]>
 */
class ArrayDisplayer implements DisplayerInterface
{
    /**
     * Get the content associated with the given exception.
     *
     * @param \Exception $exception
     * @param int        $code
     *
     * @return array
     */
    public function display(Exception $exception, $code)
    {
        $info = ExceptionInfo::generate($code, $exception->getMessage());

        return ['success' => false, 'code' => $info['code'], 'msg' => $info['extra']];
    }

    /**
     * The method to decide if this displayer should be used or not.
     *
     * @param \Exception               $exception
     * @param \Illuminate\Http\Request $request
     *
     * @return bool
     */
    public function use(Exception $exception, Request $request)
    {
        return $request->ajax();
    }
}

Then at last the getContent method in the ExceptionHandler class loops over the displayers specified in the configuration file and then sees which one to use. In this way we won't break any current setup. You wont have to publish the configuration if you don't want to.

What do you think @GrahamCampbell? Is this solution too complex?

I have installed Laravel 8 with GrahamCampbell/Exception 14.1. When I get 500 error then it just show plain text Internal Server Error and if I check error log then there is error local.ERROR: ReflectionException: Class GrahamCampbell\Exceptions\Transformers\AuthTransformer does not exist.

Code is:

public function render($request, Throwable $e) { return parent::render($request, $e);

}

Please help me to fix what exactly causing this

PHP version: (hint: php --version)

PHP 7.4.24 (cli) (built: Sep 23 2021 21:24:59) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
    with Zend OPcache v7.4.24, Copyright (c), by Zend Technologies

Description

I was using "graham-campbell/exceptions": "^15.1", and it is registered with the service provider under config/app.php -> providers using GrahamCampbell\Exceptions\ExceptionsServiceProvider::class,. However I still get the error:

In Container.php line 1017:

  Target [GrahamCampbell\Exceptions\Identifier\IdentifierInterface] is not instantiable.

I tried to add:

    "extra": {
        "laravel": {
            "providers": [
                "GrahamCampbell\\Exceptions\\ExceptionsServiceProvider"
            ]
        }
    },

still it throws same error. The laravel version I used is ^7.0.

Do you know why it happens?

How to reproduce

If I use laravel ^6.0 with "graham-campbell/exceptions": "^12.1". Everything is fine with the code.

Possible Solution

Additional context