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 it's felt good just essentially redact 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 plus error.svelte component and
create that 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 tannins.
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 fullback error page.
That comes by default with SvelteKit and we can customize this by adding
a new source/error.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 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 doing, let you specify 404 the 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 fullback page, and
that will allow you to specify a 404.html, which will be invoked for
everything that doesn't match.