Binding $errors variable in case of HTTP exceptions

[webchopin]

• Laravel Version: 5.5
• PHP Version: 7.0

Description:

Hello everyone, hope you are doing well.

Let's say you have a custom HTTP error view in resources/views/errors, let's call it 404.blade.php.
In this view, you extend a general master view including the HTML skeleton used all over the web app.
In your general master view, you also have your navbar with a login form using the $errors variable. e.g.: using it in this way: $errors->has('password')
Let's say a user enters a non valid URL and gets redirected to 404.blade.php

There is an exception stating that $errors is undefined. Indeed, $errors is used as part of 404.blade.php and should be empty.

A fix to this issue might be to bind $errors to an empty ViewErrorBag in case of HTTP exceptions. This might be done like in the \Illuminate\View\Middleware\ShareErrorsFromSession

What do you think ?
Here is the related PR: #23139

Steps To Reproduce:

1. Create a file: resources/views/errors/404.blade.php
2. Put in the file the following content:

<div class="form-group">
  <input type="email" class="form-control {{$errors->has('email') ? 'is-invalid' : ''}}" placeholder="Your email ..." name="email" value="{{ old('email') }}">
</div>
<div>
  404
</div>

3. Go to an invalid URL in your browser

[Namoshek]

I somehow find your usage of $errors a bit weird here because it is also used for initial requests where you most likely do not have any errors yet. How do you prevent the issue with the not set $errors variable for other pages like your /home site or so?

In general, you should always check for existence of variables before using them (especially if they are some sort of optional like here). Meaning @isset($errors) would be a good start here...

[webchopin]

Actually, in a route like /home with no errors in the session, $errors is set to a empty view error bag through \Illuminate\View\Middleware\ShareErrorsFromSession.
The middleware does this for convenience so that the developer doesn't have to run checks for the presence of errors.

I agree that in general, we should always check for existence of variables before using them and I saw that we have in the framework a convenient way to avoid these checks for the $errors variable. So, the PR I suggested is just an extension of this feature to the HTTP exceptions use case.

Hope this clarifies

[webchopin]

Btw, here are some comments from : \Illuminate\View\Middleware\ShareErrorsFromSession

// Putting the errors in the view for every view allows the developer to just
// assume that some errors are always available, which is convenient since
// they don't have to continually run checks for the presence of errors.

[webchopin]

PR commit has been merged : #23139