Restore view factory state on caught exception

[thierry2015]

What

Restore view factory state on caught exception.

Why

When an exception is thrown while rendering a database view, the rendering state isn't restored, leading to caching issues. This problem can be notably observed within a queue worker, where the application lifecycle doesn't terminate after an exception is caught, leading to subsequent rendering inconsistencies.

The main use case leading to this fix was the following: after failing to render a view used in a queued Mailable (view factory $renderCount was > 0 after the exception was handled), the next sent email using a file-based Blade template was successfully built (counter still ended at > 0, same value as the previous render, different cache keys within the view factory), but the third email being rendered and send (also file-based) contained the previous email context and sections, when both last two emails were derived from the same template (the two templates could be different, as long as they shared the same base template using @extend and @section).

How

When an exception is caught in the render phase, the factory state is restored (see the original View implementation.

How to test

Without this fix, using Tinker, render a DB view that is supposed to throw (e.g. omit a portion of the view-model). In the same Tinker session, render the same file-based template twice, using a different view-model. The second render should contain the previous context.

With this fix, we should no longer be able to replicate this behaviour.

[Flynsarmy]

Thanks!

[thierry2015]

@Flynsarmy Could you also tag the merged commit appropriately (I'm guessing 9.0.2), so we don't have to rely on dev-master / commit hash please?

[Flynsarmy]

Done