Check out a free preview of the full Fullstack Svelte with SvelteKit course

The "Errors & Redirects" Lesson is part of the full, Fullstack Svelte with SvelteKit course featured in this preview video. Here's what you'd learn in this lesson:

Rich walks through handling expected and unexpected errors, customizing SvelteKit's default error and fallback error page, and redirecting from one page to another. A student's question regarding web hosts expecting a 404.html file is also covered in this segment.


Transcript from the "Errors & Redirects" Lesson

>> Okay, let's talk about error handling. There are two types of errors in SvelteKit. There are expected errors and there are unexpected errors. An expected error is one that was created with the error helper imported from Sveltejs/kit, and we can see that here in the expected page server js file.

We're importing the error helper from SvelteKit, and then we're throwing an error a 420 status code, enhance your calm. And if we navigate to that page, you'll see that message being displayed. But any other error that was not created with that helper is treated as unexpected. So over here, we're throwing a new error, kaboom.

If we navigate to this page, you see the message, internal error. So the distinction is that when you throw an expected error, you're telling SvelteKit, I know what I'm doing here. This error is intentional, it's not something that we need to worry about. An unexpected error is assumed to be be a bug in your app.

So when an unexpected error is thrown, its message and stack trace will be logged to the console. If we open up the terminal here, you should see down there our kaboom message along with a stack trace. Now, later on, we'll learn how to add custom error handling. But for now, I want you to notice that when we go to the expected error, the message is shown to the user and the unexpected error it is not.

Right, that's because error messages can contain sensitive data, which could be useful to someone who is trying to attack your website. In the best case, the error message is probably gonna be cryptic and not very helpful to your users because they're designed for developers and not for users.

So SvelteKit just essentially redacts that message and displays internal error to the user. When something goes wrong inside a load function SvelteKit will render the error pages that we see. See, the default error page is a little bland. If you want to customize it we can do so by creating a +error.svelte component and create that at the root of our source/routes directory.

I'm gonna import the pagestore so that we can get details about the error. And I'm gonna import some emojis from the emojis.js file. This contains some emojis corresponding to status codes. On this page, we'll add the status, which on the expected page is 420, followed by the error message.

Then to customize it, we'll add a span make it nice and big, 10em. And we'll render the emoji that corresponds to the current status code. All right, so now if we visit the page with the expected error, we see the melting face. And if we go to the unexpected error page, we'll see a kaboom emoji.

Now you'll notice that the error.svelte component is being rendered inside the layout.svelte. And we can create more granular error boundaries than the root one inside expected page let's create a new error.svelte. And inside that file, we'll say this error was expected. And now if we navigate to that page, instead of showing the root error page.

It's going to show a more specific error page. And you can have as many of these error boundaries as you like at whatever depth of your app. Now, sometimes things might go really wrong. For example, you might have an error that occurs while trying to load the root layout data.

And in that case, there's basically nothing that SvelteKit can render, so it has to fall back to a fully static error page. We can force this to happen by opening up a new file, layout.server.js. And inside the we'll add a load function. I'm just gonna deliberately throw an error like this, and so what we're looking at now is the fallback error page.

That comes by default with SvelteKit and we can customize this by adding a new source/error.html file alongside source/app.html. Click the New File button error.html. And then here we can put whatever we want. We can use the SvelteKit status placeholder, and add another one for the error message. And we also use the throw mechanism to redirect from one page to another.

So inside this file source/route/a/page.server.js, we're gonna add a load function. It imports the redirects helper from SvelteKit. And uses it to redirect the user. From a to b. Now if we try navigate to a, it'll just take us straight to b instead. So you can throw redirect inside load functions and inside form actions, API routes and the handle hook, all of those we'll discuss later.

The most common status codes that you'll use here. It'll be 303 which means 'See Other'. We'll use that following a successful form submission. Sometimes 307 is a temporary redirect, and 308 is a permanent redirect. In this case we're using a temporary redirect from a to b.
>> Some web hosts expect like 404.html file?

So that would apply if you're baking out your site as a set of static HTML pages. Some web servers do indeed, let you specify 404.html which will basically be for everything that doesn't have a file already created. If you're using one of those web servers, then you're probably gonna use something called adapter static, which we'll bring up the docs for.

So we have a page here on static site generation. When you're using adapter static, you can create what's called a fallback page, and that will allow you to specify a 404.html, which will be invoked for everything that doesn't match.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now