Take a look at this. So once again, we have a resource for Post, just to keep it simple. And now let's imagine there's some kind of logic that says if this criteria is met, the Post is private, in which case we want to ban the user from visiting that page. I'm just going to simulate that for now by throwing an exception. So I'll say something like PostIsPrivate. All right, that may be thrown from your domain model, whatever you want. Just imagine at some point in the code, a check is performed, and we throw an exception. Okay, let's go ahead and create that. App\Exceptions\PostIsPrivate. And I'll build that up like so. And that will extend the generic Exception base class. Okay, so now let's try it out. So we're going to go to laravel55.dev/posts/anything at the moment. And we can see PostIsPrivate not found. That's because we need to

Okay, so now let's try it out. So we're going to go to laravel55.dev/posts/anything at the moment. And we can see Post is private not found. That's because we need to import it at the top. Let's give it another run. And yeah, when we visit that route, at some point we are throwing this exception. Okay, so now imagine you want to handle that in a certain way. Like maybe you're going to say try to do a postShow or whatever it happens to be. In this case, we're just going to be dumb and throw it immediately. But yeah, we're going to catch Post is private. And then in this case, maybe you redirect back to the home page. Maybe you flash a message, whatever you need to do. Okay, so this is pretty common for how these things are handled. We run it. Sure enough, the exception was thrown at some point in our app. We caught the exception, and then we redirected with a flash message or header or something like.

these things are handled. We run it. Sure enough, the exception was thrown at some point in our app. We caught the exception, and then we redirected with a flash message or header or something like that. Now, one step, this is all still standard Laravel, by the way. But one refactoring step is if this will happen a lot in your blog or whatever it happens to be, one thing you can do is let the exception bubble up, and then you can handle it in a more generic spot. So App\Exceptions\Handler. And then here is where we render the exception. So what you could do, this is, again, traditional Laravel 5.4 stuff, is we could say, well, if the exception is an instance of PostIsPrivate, and let me import that at the top. If that's the case, then here, maybe you want to return a custom response or a redirect response. So yeah, you could let it bubble up all the way here, and then handle it once again if it makes sense. So now I can switch

maybe you want to return a custom response or a redirect response. So yeah, you could let it bubble up all the way here, and then handle it once again if it makes sense. So now I can switch back to PostController and get rid of this try catch entirely, like so. And again, at some point in our logic, we're imagining that this exception gets thrown. Okay, so we give it another run. And sure enough, that redirect takes place because, again, it bubbles up and we handle it here. So if I didn't have that and we give that a shot, yeah, now we get the standard exception that we didn't handle. Okay, good to know. But now here's the reality. For real projects, if you're doing this approach, you may, after six months or a year, end up with things like this, and it starts to feel really gross, right? So what you can do in Laravel 5.5 is throw this rendering logic directly into the exception itself, like this. I'm going to comment this out. Let's give it a refresh. Run it.

really gross, right? So what you can do in Laravel 5.5 is throw this rendering logic directly into the exception itself, like this. I'm going to comment this out. Let's give it a refresh. Run it. Yeah, we still see that. But now, if I go into the exception class, I can render it here. So render the request. And now, yeah, I will return a custom response or a redirect response in this case, whatever you need to do. Okay, let's give that another shot. And now we're handling it. So yeah, this is the new thing in Laravel 5.5. If you're letting exceptions bubble up to the handler class and in the past you were type checking them like this, well now it's still fine if you want to do that. But if it starts feeling gross and you want to refactor, you can take that logic and you can throw it into your exception class here. And there's also a report method if you want to handle bug snag reporting and what to do there. So now our HostController can be clean. You don't need

throw it into your Exception class here. And there's also a report method if you want to handle bug snag reporting and what to do there. So now our HostController can be clean. You don't need to try catch there if it's not necessary. That will bubble up to the handler where we render it. And then as part of that, and in fact I'll just show you real quick, here is the parent class. So let's go to that where we render it. And here we go. So if there is a render method on our exception, and there is, well then we call that render method and we return the response and then prepare that. And then also just as a side note, if the exception is an instance of Responsable, well then we can convert that as well. So if that makes sense, implements the Responsable interface, well then we could have to response where we convert that to a response. Like so. That would be an option as well. So let's come back one more time.

interface, well then we could have to response where we convert that to a response. Like so. That would be an option as well. So let's come back one more time. Oh, and whoops, I forgot to accept the request. All right, run that again. And yeah, now that would be another way to handle it. But yeah, I think traditionally for exception handling, you'll take the approach that I showed earlier, where you define a custom render method on your exception.