which is added to the pipeline class, which means that we can do tidy up after something has happened, once something fails, whatever we need to do. Let's take a look at a demo of this, and I'm using pretty much the example directly from the pull request over on GitHub to demonstrate this, just because I couldn't think of a better idea. Okay, so let's take a look at what we're

doing with our application. So we've got this deployment model in the database. This has a couple of columns that I've filled in, deployed at and stopped at. Deployed at will only be run once all of the steps that we are piping the deployment through have finished, but what we want to do is do an additional clear up step at the end and also fill in stopped at, regardless

of whether it was successful or not. Now of course this is a really basic example, but you can apply it to everything you're doing. Okay, so when we work with the pipeline, we're passing this object, this model that's been created through this create server just here, which can potentially throw a new exception. We get the deployment through here that we're passing through the

pipeline, and we get a next closure as well, which we invoke passing the current state of the deployment through to. Now this will fail if we don't call next or if we throw an exception, so that is when finally would usually get called. Let's go and just take a look at the other action that we have here. This just does absolutely nothing, and let's go ahead and just run this

in the browser and see what this looks like by default. So you can see here that deployed at is reached because both of the steps were taken or the deployment went through both of the pipeline steps, and let's take a look at what happens if things fail. So for example over in create server, if we get rid of the comment here and actually do throw this exception, what's going to happen here?

Well let's go ahead and run this, and of course we get the exception out here, but we want to feel this stopped at regardless of whether it failed or not. So we'd want to do a kind of final tidy up of everything. Now how would we normally do this before this change? Well we would use a try block, we would emit catch, there's no point in using catch here unless we actually wanted to catch

the exception, but we can use finally. This is just base PHP stuff that we can use. Then what we could do for the deployment is we could go ahead and touch the stopped at timestamp, and maybe we could do some other tidying up here. That would mean that if we go over now and give that a refresh, that throws that exception, but with the try finally block this will have gone ahead and

filled in stopped at for for us. So you can do pretty much anything you want in here, but this potentially looks a little bit messy. There's nothing wrong with doing it like this, but when we're talking about Laravel we're talking about fluent code, and now we have the ability to use a finally closure with a fluent method. So we can use finally here, let's get rid of this,

and we'll just say before, and we'll go ahead and comment this out. Now let's take a look at after. So we can get rid of the try catch or try finally block, and we can create this so it's a little bit tidier. Now finally doesn't go onto the end of here because the result of then is actually a boolean, so you don't want to add it onto the end of then. You want to do it as a sort of in-between step.

Now for this what we would do is either create out a separate class that could handle an invoke here to do lots of tidying up if you wanted to split this out, or you could do a long or short closure. It doesn't really matter what you do. Either way we want access to that deployment, and we want to do exactly the same thing. So let's say deployment touch and stopped at, and that should have exactly

the same effect as we saw before. We get a failure within one of them pipelines and stopped at is filled. So a really basic change, but if you are using pipelines and you are doing some clear up based on any of the things that you're piping this through failing, then this is going to be a welcome change rather than having to wrap it in a try finally.