Breaks self rendering exceptions (contains render method)

[4n70w4]

Hi! I also really hate Laravel's native exception handler.

Laravel Nova contain AuthenticationException with render method https://gist.github.com/4n70w4/3e17c2df500527be3f603c32ab7e2762

Switching to this library completely breaks the work of the Nova.

Also I found ~ 3 500 similar exceptions with render method on github.

All of them will not rendered correctly when using this library.

https://github.com/search?p=5&q=%5CIlluminate%5CHttp%5CResponse+%22function+render%28%24request%29%22+NOT+Handler+%26+NOT+OAuthServerException+extension%3Aphp+filename%3AException&type=Code

I know that you are extremely against the changes in the method \GrahamCampbell\Exceptions\ExceptionHandler::render

However, the easiest way is to make this change.

Replace

$response = $e instanceof Responsable ? $e->toResponse($request) : null;

to

        if (method_exists($e, 'render') && $response = $e->render($request)) {
            $response = $this->container->get(Router::class)->toResponse($request, $response);
        } elseif ($e instanceof Responsable) {
            $response = $e->toResponse($request);
        } else {
            $response = null;
        }

Alternatively, can make a separate displayer for this. My example implementation: https://gist.github.com/4n70w4/39cc0441eea9c6b94512ff2443009bf8

This is a very common scenario. I don't understand why it is not included in this library.

Switching to this library breaks some components. It is sad.
Many people will have to do the same job over and over to solve this problem.

[GrahamCampbell]

This was a design decision. Exceptions should not know about responses. This package is intentionally very opinionated out of the box, but also very flexible. If you want to implement a "displayer" to do this, you can. :)

[4n70w4]

@GrahamCampbell but design not described on docs. Or I couldn't find it. Searching the repository does not return any results.

I see cases for \Illuminate\Contracts\Support\Responsable, \Illuminate\Http\Exceptions\HttpResponseException and \Symfony\Component\HttpFoundation\Response. But don't see case for https://laravel.com/docs/7.x/errors#renderable-exceptions. It very much confused.

Maybe should also move Responsable, HttpResponseException, Response from ExceptionHandler::render to separated displayers? For uniform design.

[GrahamCampbell]

To write a displayer, you just need to implement this interface: https://github.com/GrahamCampbell/Laravel-Exceptions/blob/15.0/src/Displayer/DisplayerInterface.php. There are some examples in https://github.com/GrahamCampbell/Laravel-Exceptions/tree/15.0/src/Displayer.

[4n70w4]

@GrahamCampbell Yes, I know how to do it. I don’t understand why you wrote this.

[GrahamCampbell]

You're free to implement displayers that do what you want in your app. :)

[4n70w4]

@GrahamCampbell so why in your design only this type of exception is excluded, and the other exception types hardcoded in the render but not in separate displays? This is incomprehensible and confusing.

I would be interested to read more about this design. You probably know what I don't know.