Update custom errors info

[laurencei]

So the docs are not explicitly obvious that a 500 error due to an internal server issue will still cause a "whoops" page to be displayed, even if you have a custom "500.blade.php" in your errors folder.

Personally I think it would make much more sense to just allow all 500 errors to be displayed as a custom page (because if you if set a 500 error view - that is what you expect to be displayed). But there are multiple issues that have suggested this that have been closed:

laravel/framework#17586
laravel/framework#14137
laravel/framework#10466

So this PR just updates the docs to make it a bit more obvious...

[taylorotwell]

It is only instances of Symfony\Component\HttpKernel\Exception\HttpException that use the custom HTTP error pages. If you want to make all exceptions use those pages you would need to convert all other types of exceptions to HttpException in the render method of the exception handler. This may be something we want to do in the core for Laravel 5.5 (or even 5.4). I'm not sure this documentation really accurately describes what is happening.

[laurencei]

Thanks @taylorotwell - I was thinking of doing a PR for something like this - but given the other issues were closed - I wasnt sure you'd be open to it.

I'll submit something for 5.5 and let me know what you think...?

[taylorotwell]

I think it could raise a variety of other issues to do it. Does your custom 500 page contain a "debug" mode that contains the stack trace? If it doesn't, people will make custom 500 pages and complain they can't see the stack trace of the error.

[laurencei]

You can do something like (pseudocode)

if ( ! config('app.debug')) {
   return custom 500 page if it exists
}

display current whoops page

That keeps current behaviour in development (for stack traces), and lets you override the 500 page only if you want in production.

[taylorotwell]

Yeah something like that might be reasonable.

[AdamEsterle]

@taylorotwell @lioannou Here is my solution I posted about on Laracasts
https://laracasts.com/discuss/channels/laravel/change-whoops-looks-like-something-went-wrong-page?page=1#reply-327058

Override the convertExceptionToResponse function.

Why? Because it gets called in the renderHttpException function if there is not a view for the error. I.E. No 404.blade.php file if a 404 error is thrown. It also seems to be the "catch all" function if the error is not a validation error, http error, etc.

protected function convertExceptionToResponse(Exception $e)
    {
        if (!config('app.debug')) {
            return response()->view('errors.500', [], 500);
        }

        return parent::convertExceptionToResponse($e);
    }

This would override the function found in \Illuminate\Foundation\Exceptions\Handler

I also found the 500 internal error vs the 500 http error confusing. This was the best I came up with.

[browner12]

sorry to highjack this a little bit, but I've always thought it would be great if the HTTP exceptions could be sent through the normal routing. This way you could have something like an ErrorController with

public function 404()

public function 500()

etc

IMHO this would make the error handling a little more consistent with normal operation.