All of this is well and good when you have absolutely no bugs, but what happens when you need to debug one of your serverless functions? There are a couple of different ways you can do that. Let's look at index.js to start. We have an empty handler here, but wait, where does this go? If we say console.log, hello from lambda, where does this go? Because it's running in lambda, you might not be super familiar with where this log statement goes. We will run sidecar deploy --activate. Let's hit this from the browser, return hello world, execute.

We will run sidecar deploy --activate. Let's hit this from the browser, return hello world, execute. And we're not returning anything, so we're not going to see anything in the browser. We'll come over here and hit serverless.whip anyway. As expected, we're not seeing anything. Where does that console.log statement go? One place is we bring it back into sidecar. If we call this result, we're returning result to the browser. What if we dump result logs? It's not beautiful, but we do get the logs from the function.

What if we dump result logs? It's not beautiful, but we do get the logs from the function. That's one way you can see it. Another place you can see it is in your AWS console. You come in, you click on your function, come down to monitor. You can click view logs in CloudWatch. You see we're now in a log group for sc-serverless-hello-world. You can see you've got a bunch of prefixes here, 20, 21, 22. Those are your Lambda versions, so we'll click into the most recent one. In here, you get a whole bunch of information.

But we also have the raw AWS result. So we have all of this information in here. So if you need to get at it, you can. We have a couple of helper functions on the settledResult, which is what this is. This is a settledResult. So you can call buildDurationMilliseconds, toMilliseconds. Cold boot delay, zero, cuz it's not a cold container, it's already warm. We've been running it over and over. You can get at that report.

We've been running it over and over. You can get at that report. So we try to give you as much context as possible in this settled Result class. And if you need it, you can always get at the raw AWS result by calling the raw method. I wanna look next at this isError method. Because we use that isError method in this throw method down here. So we've looked at log statements. I wanna look at actual errors. Let's create a super obvious error.

I wanna look at actual errors. Let's create a super obvious error. We're gonna return foobar.baz. Now, foobar doesn't even exist. So trying to pull .baz off of it, that should just throw an error. Let's deploy again. We'll come back to web, get rid of this dd, and then we'll return the body. You'll see if we refresh, we do get this messy error. It does tell us what is going on, so that's helpful. But let's look at the network.

It does tell us what is going on, so that's helpful. But let's look at the network. It's still a 200, so that's not super ideal, because now we're returning an error. But with a response header that says it's okay, so php's not catching the error. So we're likely returning the error to the end user, which is definitely not great. Sidecar does have a way to manage that. So let's pull this again. We'll pull that out.

So let's pull this again. We'll pull that out. We'll say that $result is equal to that, and we want to return $result body. In the middle here, we can say $result throw. Now if we refresh, look at that. If we get a 500, we get a big nasty error that shows us something's gone horribly wrong. It shows us that that definitely came from our hello world execution. And if you look at this, we even try to take the actual error message from lambda, and make that the error message in PHP. So you're immediately aware of what is going on.

and make that the error message in PHP. So you're immediately aware of what is going on. And the great thing about this throw method is that if there's no error, it just returns itself. So you can always call throw, and not have to really worry about it. So you would likely do something like that, result throw body. Because if you got rid of this error, and we just returned hello, and we refresh, we see hello. So you can always call throw to turn your lambda exceptions into actual PHP exceptions, which would likely then get caught by the framework, and show your end user something pleasant, rather than foobar not defined.

which would likely then get caught by the framework, and show your end user something pleasant, rather than foobars not defined. We've kind of been doing it manually here. I want to show you what happens if you return hello world execute. So what happens if you return a settled result directly to the browser? Well, you get the exact same thing. You get hello. Let's throw an error again, and see how that's handled. We'll refresh. And we get the full on PHP error.

We'll refresh. And we get the full on php error. So what is going on behind the scenes? Behind the scenes, every lambda function actually implements a toResponse method. And in the toResponse method, you'll see something that looks very familiar. First, we throw if there's been an exception, otherwise, we return the body. Every time you return an object, Laravel is going to look to see if it has a toResponse method on it. And if it does have a toResponse method, it's going to call that, and it lets you control how the response is rendered to the browser.

And if it does have a toResponse method, it's going to call that, and it lets you control how the response is rendered to the browser. So that thing that I showed you where I said you could do throw, and then you could do body, that's exactly what's happening. You can just return a settled result to the browser, and sidecar is going to do throw, and it's going to do body for you. And of course, you're free to hook into this as well. You could say that your toResponse, you do want to throw, and you do want to return the body, but you also want to do something with the result logs. You maybe want to log the logs, or if the result is an error,

you do want to return the body, but you also want to do something with the result logs. You maybe want to log the logs, or if the result is an error, you want to log all of the logs, and then go ahead and throw the error. This is a great place to hook in to do a little bit more debugging if you need to.