[5.7] Removed UnauthorizedException

[amadeann]

#23674 with fixed spacing.

---

Original message for reference:

This PR removes the UnauthorizedException, which is no longer used in the framework. I've raised this issue here: laravel/ideas#1047, and it was accepted as a candidate for PR by Taylor.

To summarize:

UnauthorizedException was only used in failedAuthorization method in Illuminate/Validation/ValidatesWhenResolvedTrait.php. This trait is used only in Illuminate/Foundation/Http/FormRequest.php, which overrides the failedAuthorization method throwing AuthorizationException instead. UnauthorizedException was therefore never thrown by the framework itself, so I don't think we really need it.

[sisve]

which is no longer used in the framework.

Isn't that a bit misrepresentative when your PR clearly shows that the exception was used before you changed it?

Anyhow, what's the upgrade path for every application and package that was throwing this exception? Would it make sense to deprecate the exception class for one release according to laravel/ideas#383?

[amadeann]

By 'no longer used in the framework' I meant that the only place where the UnauthorizedException is thrown in Laravel framework (not independent packages, or apps) is not reachable.

Taylor replaced virtually all references to this exception with AuthorizationException in 1f804b9

for consistency with ValidationException.

The only place where he left it was failedAuthorization method in the Illuminate/Validation/ValidatesWhenResolvedTrait. However, since 7e33410 this method is overwritten in Illuminate/Foundation/Http/FormRequest, which is the only place using that trait.

My only objective in removing this was cleaning up the framework from the old code - not to make Laravel 'heavier' than necessary. If you think it should stay there, no hard feelings :)

[taylorotwell]

One problem with changing it to this exception is that the validation component does not require the illuminate/auth component in its composer.json file, so it would not have access to this exception when being used in a stand-alone package. That may be a rare situation, but something to consider here.

We would either have to throw a more generic Exception and let anyone who is using this manually define their own exception or leave it as-is.