Capture Your First Error with Sentry — Transcript

Transcript of the free Vue.js lesson Capture Your First Error with Sentrywatch the video lesson.

Now that the Sentry SDK is installed, we can trigger our first error to see how things will look in Sentry. Let's open up the home page and add a button. Let's say it's a checkout button. And on click, I'll call a function called checkout.

Next, we'll use the View3 script setup syntax to create the checkout function. And for now, checkout will just throw an error. letting us know that we've not yet implemented the details of the function. Okay, let's see what happens when we click the checkout button in the browser.

If you open up the console, you'll see that we don't get the error in here as you might expect. js. Back in the browser. If we try clicking the checkout button again, sure enough, we see the error in the console.

Nice! Let's go take a look in the Sentry dashboard and see what the error looks like there. If you still have the installation instruction page up from the last lesson, you can click the Take me to issues button. Otherwise, you could navigate to the issues on the left hand side.

Alright, now we can see where Sentry has captured our issue. Awesome! This means that even if we aren't there to see the error in the console, we can still see the error in Sentry. This is perfect, since we can't go and look over the shoulder of all of our users and inspect all their consoles.

Let's click into the issue now and see what other information Sentry has for us. Okay, wow. Right off the bat, we've got quite a lot of information to work with here. First, Sentry tells us that this is a new issue.

that has surfaced recently. It also tells me how often the error has occurred. That is, twice. And that's exactly right, because we tried it once with log errors off, and once with it on.

A quick note on naming conventions in Sentry. Sentry is smart enough to group the same or very similar errors based on their stack trace and other data into a single entity called an issue. This is very helpful, as we don't think of individual occurrences of an error as an issue, but rather all occurrences are a consequence of the same issue. Cool.

It also tells us how many users it's affected. I assume right now that this is based off of an IP address. It also gives us some information about the user's machine, browser, and so on. That could be pretty handy.

If we scroll down now, we can see a stack trace of the issue. And while this isn't very helpful and doesn't have a whole lot of information right now, we'll see how to make it useful later with source maps. Continuing down the page, we get a section here called breadcrumbs that looks like it holds some pretty useful info. We've got the navigation picked up from view router that tells us exactly what page we were on and also a very precise selector.

that shows us the exact element that was clicked, and finally the error from the console. Lastly, we get some useful info about the request, the user, the browser, the device, the operating system, some view specific information, and information about the Sentry SDK itself. Let's now click Mark Reviewed as we've gotten an initial look at it. and notice that the new issue label has gone away.

With that, we've taken the first step, that is, getting visibility into the issue, to resolve our error. Now that the Sentry SDK is installed, we can trigger our first error to see how things will look in Sentry. Let's open up the home page and add a button. Let's say it's a checkout button.

And on click, I'll call a function called checkout. Next, we'll use the View3 script setup syntax to create the checkout function. And for now, checkout will just throw an error. letting us know that we've not yet implemented the details of the function.

Okay, let's see what happens when we click the checkout button in the browser. If you open up the console, you'll see that we don't get the error in here as you might expect. js. Back in the browser.

If we try clicking the checkout button again, sure enough, we see the error in the console. Nice! Let's go take a look in the Sentry dashboard and see what the error looks like there. If you still have the installation instruction page up from the last lesson, you can click the Take me to issues button.

Otherwise, you could navigate to the issues on the left hand side. Alright, now we can see where Sentry has captured our issue. Awesome! This means that even if we aren't there to see the error in the console, we can still see the error in Sentry.

This is perfect, since we can't go and look over the shoulder of all of our users and inspect all their consoles. Let's click into the issue now and see what other information Sentry has for us. Okay, wow. Right off the bat, we've got quite a lot of information to work with here.

First, Sentry tells us that this is a new issue. that has surfaced recently. It also tells me how often the error has occurred. That is, twice.

And that's exactly right, because we tried it once with log errors off, and once with it on. A quick note on naming conventions in Sentry. Sentry is smart enough to group the same or very similar errors based on their stack trace and other data into a single entity called an issue. This is very helpful, as we don't think of individual occurrences of an error as an issue, but rather all occurrences are a consequence of the same issue.

Cool. It also tells us how many users it's affected. I assume right now that this is based off of an IP address. It also gives us some information about the user's machine, browser, and so on.

That could be pretty handy. If we scroll down now, we can see a stack trace of the issue. And while this isn't very helpful and doesn't have a whole lot of information right now, we'll see how to make it useful later with source maps. Continuing down the page, we get a section here called breadcrumbs that looks like it holds some pretty useful info.

We've got the navigation picked up from view router that tells us exactly what page we were on and also a very precise selector. that shows us the exact element that was clicked, and finally the error from the console. Lastly, we get some useful info about the request, the user, the browser, the device, the operating system, some view specific information, and information about the Sentry SDK itself. Let's now click Mark Reviewed as we've gotten an initial look at it.

and notice that the new issue label has gone away. With that, we've taken the first step, that is, getting visibility into the issue, to resolve our error.