DejaVue

All of you have seen users do weird things with your application and running into strange scenarios - who can't relate to this?
For this and many other reasons, the right way of error handling is important in you application. Join Michael and Alex on a discussion of the different ways one can handle errors in their application.
That includes not always showing an error page, but also handling errors request-based or component-based!

On that note, error messages and how to write decent ones that are helpful for the users are discussed, as well as how components like NuxtErrorBoundary work under the hood

Enjoy the episode! 

Chapters

  • (00:00) - Welcome to DejaVue
  • (01:22) - The good old error page
  • (01:58) - Write good error messages!
  • (03:11) - The Vue global error handler
  • (05:07) - Server vs. Client Errors in Nuxt.js
  • (08:34) - The vue:error hook
  • (09:05) - Global error handling for $fetch and interceptors
  • (11:10) - Throw unhandled errors in Prod with Vue 3.5?
  • (13:07) - Component-level error handling
  • (16:33) - NuxtErrorBoundary
  • (18:01) - defineAsyncComponent
  • (18:53) - Request-based error handling
  • (21:45) - New default values in Nuxt 4
  • (23:30) - Error Tracking
  • (26:33) - Actually handling the errors
  • (28:54) - Wrapping up

Links and Resources


Your Hosts

Alexander Lichter

Michael Thiessen

Links marked with * are affiliate links. We get a small commission when you register for the service through our link. This helps us to keep the podcast running. We only include affiliate links for services mentioned in the episode or that we use ourselves.

Creators & Guests

Host
Alexander Lichter
Web Engineering Consultant • Founder • Nuxt team • Speaker
Host
Michael Thiessen
Full-time Vue educator
Editor
Niki Brandner
Sound Engineer

What is DejaVue?

Welcome to DejaVue, the Vue podcast you didn't know you needed until now! Join Michael Thiessen and Alexander Lichter on a thrilling journey through the world of Vue and Nuxt.

Get ready for weekly episodes packed with insights, updates, and deep dives into everything Vue-related. From component libraries to best practices, and beyond, they've got you covered.

Alexander Lichter:

Hello, everybody, and welcome back to DejaVue.

Michael Thiessen:

It's your favorite Vue podcast. You just don't know it yet. Although, we're, like, 35, 36 episodes in. So maybe at this point, you've already figured out whether you like this podcast or not. And if you don't like it, then why are you still here is my question.

Alexander Lichter:

Yeah. You should you should write a comment why you don't like it. Like, give us some constructive criticism Yeah. And tell us. Or if you like it, then watch all the previous episodes.

Alexander Lichter:

Maybe it's not your first episode here, and you know all of them. Nevertheless, we're here to talk about a topic that's relevant for all of us, error handling. Right? But before we come to that, a quick hint. There is the State of JS survey open right now.

Alexander Lichter:

Link for that also in the show notes slash description. So if you wanna vote for, well, not only your favorite framework, but also maybe your favorite podcast or content creators, that's up to you. You can do that now. So it would be nice if you could, well, share some, some nice, inputs there and given your opinion.

Michael Thiessen:

Yeah. So today, we're gonna cover error handling. So sort of starting from the big picture with, like, full page errors then moving down to more fine grained component level stuff, and then even, like, more request based things. So we're gonna start big and sort of narrow away in.

Michael Thiessen:

And so to start, we've got page errors.

Michael Thiessen:

And so in, lots of places that I've worked at, this is all that we ever really did. We Exactly. We had an error, and we would just say, well, there's an error and throw up, I don't know, like, a full page screen kind of get rid of everything that was on the page and just say, hey, something broke. Sorry about that. Maybe it wasn't even like a customized error message.

Michael Thiessen:

It was just a pretty generic error message saying, retry whatever you just did. And, that was that was basically it.

Alexander Lichter:

Yeah. Like these are, oh, yeah. Something wrong. Please try again later. I always feel like these are the the horrible like, the most horrible server, like, error messages you can ever get because you never know, like, okay.

Alexander Lichter:

It's it's this is it on them, like, on on you as a developer? Is it on on the user? Like, did I do something wrong with the application? So yeah. It's I mean, sometimes you don't have any chance.

Alexander Lichter:

Right? You just said, like, okay. Something went wrong. Not sure what exactly, so I have to just, like, blow up the whole application and be like, okay. That's it.

Alexander Lichter:

But in, like, in lots of cases, there are better ways which we'll go through after talking about the page errors, of course. And I think before we get into the details as well, like, the error message, it's so important that if you at least have some information about it, and it would be good to know, okay. What's the problem and how to solve it. Like, I don't know. Let's say you register and you given your email, then you also don't wanna say, like, oh, yeah. Can't register account. You want wanna say, like, oh, yeah. This email is already registered and maybe give a solution like, hey. Do you just forget your password and click here to get a new one? Mhmm.

Alexander Lichter:

So it's also important to be very intentional with the error message. And even if you just add the reason, that's a good start, but there is definitely more that can help the user and make them happy again after seeing errors.

Michael Thiessen:

Yeah. And so the way that, like, Vue comes with this error handler with that, like, a global thing. So if you have any errors anywhere in your Vue app, they get bubbled up just like, you know, an event or like a an error in any JavaScript application gets if it's not caught anywhere else, then it gets, you know, it keeps going up and up and up, and then it gets to the top level, and then you handle it there. And often when we handle this, we're hooking into some sort of, like, 3rd party service to track these errors, like Sentry, Bugsnag, Rollbar. They let us track the errors and we can come in later and see what happened and help us debug some of the things that are going on there.

Alexander Lichter:

Exactly. And then, of course, you might wanna show that error message saying, oh, yeah. No no clue what happened here because if it bubbles up that far and was not called before, then, yeah, you you might simply not know. Or maybe you have some general logic like, oh, if it's, I don't know, a 401 error. It's like, hey.

Alexander Lichter:

That user is not authenticated anymore. Let's throw them out and not show an internal server error, but more like, hey. You're not registered. Like, you're not logged in anymore, not authenticated. So please do that again.

Alexander Lichter:

So there's also a good space for that. And yeah. And and Plainview, as you said before, you have this wonderful global error handler that you configure, and and that works in, yeah, any kind of your application. So that's that's at least a a good level to start and also to make sure that you have your tracking set up nicely.

Michael Thiessen:

Yeah. At that point, because you've lost some of the context of what was going on, you do get the error. I don't know. Do you get where the error was from? I'm not sure on that detail, but

Alexander Lichter:

You should get a stack trace. Yeah. Probably.

Michael Thiessen:

Yeah. But I mean, at that point, it's still it's much harder to give it appropriate error message or whatever. And and, yeah. But definitely a a good first step.

Alexander Lichter:

Exactly. And there are a few more things that you can do if you're using Nuxt.js if it comes to, like, coarse. So, like, coarse errors, like, just throwing up an error message. But there, it's also important to make a distinction between server side errors and client side errors.

Alexander Lichter:

Because if you have a big SPA, right, and then there's something happening, as said before on a client, then you don't always have to throw up that error page. But if you have an error on the server side, well, then the request can't really finish. You don't get any HTML back. So you don't really have another choice. You have to say, like, okay, here's an error.

Alexander Lichter:

Maybe you still guess based on the status code what went wrong. Maybe there's an, I don't know, API that says, hey, too many requests. Sorry. I'm out. So you you might get that information still.

Alexander Lichter:

But all in all, yeah, you can't do much than say, hey, sorry, site not reachable. So you really wanna track these errors and make sure they rarely or ideally never happen.

Michael Thiessen:

Yeah. For sure. And, I've been confused by this my self, the differences between the client side and the server side errors in Nuxt. And so through mastering Nuxt, I encountered this and I ended up writing, an article or a couple articles even, on error handling and like realizing that so Nuxt comes with these methods, like clear error or use error. And that uses these like global server side set errors, which is different than these, like, the error that you get with, the Nuxt error boundary component.

Alexander Lichter:

Which we'll also talk about in a bit. Exactly. But it's more like of a global versus local error problem, a bit like with global state and local state. And, like, if you clear global state, then local state might still be there and all of that. But it's that's a really good point.

Alexander Lichter:

Also, links to the articles will be, of course, also in description slash show notes. That's that's the least we can do. Right? So, yeah, that's that's definitely helpful. There is also an error.vue page that is shown if there's, like, an uncalled error in in Nuxt.

Alexander Lichter:

So if you set it up, I would always recommend that even a simple one of your own, like, branding stuff or some fun cat GIFs, like what I usually tend to do. Otherwise, there's a default one as well because you at least wanna show something. So that's nice. And you can also throw an error in in Nuxt and then say with a frocreate error, you can decide, is it a local error? So just by doing that, or is it a fatal error?

Alexander Lichter:

And you should actually show the page by saying fatal true. So also there, you have the choice of either saying, okay, this component will error out somewhere then at a component level, or you know what? This is that problematic. We'll need to show that good old, 500 internal error or whatever error is, error page there.

Michael Thiessen:

Yeah. And in that error page, you can get some information of the error, like the the status code and the actual error message itself. And so you can kinda like we what we were saying before with maybe show, like, some different error messages based on, like, oh, you got a 401 or a 500. You can have a little bit of, nuance there. Not a lot, but you can still show some different things.

Michael Thiessen:

Maybe give the user some different actions there again. It's the same kind of problem you're solving, but with Nuxt, it's in an error a special error page versus, in Vue, you've gotta, you know, put that together yourself.

Alexander Lichter:

Exactly. And if you still want to have some kind of global handler, so to say, there's also the vue:error hook in Nuxt. So it's a runtime hook. It's always important to differentiate between build time hooks and runtime hooks. Also, it runs on the on the client.

Alexander Lichter:

Right? So whenever there's a Vue error, that will also be fed in there, and then you can also do things like, show a toast or log that and so on. So there is also plenty of space there, which is pretty lovely. And also the Vue error hook is used under the hood for the NuxtErrorBoundary component, which we'll talk about in a bit. I think besides that, also a very common question that people see, like, we have this dollar fetch for for data fetching, which we talked about in a previous episode, which you definitely take a look at, about data fetching Vue and Nuxt.

Alexander Lichter:

And a lot of people is like, okay. How can we do global error handling? Because, of course, if your fetch request fails, it doesn't mean necessarily your Vue application will output an error. Right? So then people are like, okay.

Alexander Lichter:

How can we do that? And commonly, it's the easiest way to say, okay. I might wanna have different ways of handling errors based on the API calls so you can create your own dollar fetch instance, and then you have interceptors there and say, okay. If the response is an error, then you can do stuff, and you can register that in the Nuxt plug in and then just make sure, alright. Makes sense.

Alexander Lichter:

I will then call something. I will forward it error with vue:error hook, or I'll show toast or whatsoever. So if you need something more global that that works there, otherwise, you can also do it per request if you have different actions there as well. You can even combine both approaches.

Michael Thiessen:

Yeah. That's a good point. I think I haven't used the, those interceptors very much. And so I always forget that they're there because, you know, I just haven't gotten used to using them yet.

Alexander Lichter:

I think also like it's it's not something I would use every day because especially with like use fetch, use case data, you have like that error ref that you can use to say like, oh, there's an error on a template with watching that. And that's usually a good option. I think interceptors are mostly interesting for things like, as mentioned before, like these authentication topics. Oh, you're not authenticated anymore. Maybe you also wanna do something not only showing error, but maybe you wanna redo the request before fetching a new access token with the refresh token, something like that.

Alexander Lichter:

That's also everything you can do there.

Michael Thiessen:

Especially for, like, global behavior like that where you want this to happen for every single time you fetch, not, like, always checking the error you get back and then having to, like, implement extra logic. You can just, like, bake that in to that abstraction there and just, you know, not worry about it.

Alexander Lichter:

Exactly. That's what's the most common use cases there for them.

Michael Thiessen:

Yeah. And so in, doing some research for this episode, I noticed that there was this new config flag in Vue 3 dot 5, which I missed. And, it's the app dot config dot throw unhandled error in production. So my initial assumption was that this one was for, you know, if you're trying to debug some sort of error. Normally, in production, those errors are, silent, and they just get put into the the console.

Michael Thiessen:

But, Alex did a little more digging and, figured out that there was a linked issue for that.

Alexander Lichter:

Yeah. Exactly. So it was actually more about the server side errors. So when you do SSR and there's, like, the render to string method, like, really low level from Vue, let's basically say, okay. Take that componentry and render it as an HTML string, then that could fail.

Alexander Lichter:

Right? That could error. And in production, these errors are just swallowed. So while Nuxt has a way already built in to deal with that and show your error page because, well, there's Nitro behind it and so on and so on, Other SSR solutions like Vike, aka a Vite plugin SSR back in time, I think Vue plug in as but now it's it's, like, every it's universal. You can build any kind of as our application with that.

Alexander Lichter:

Of course, they they had a little bit less around it. And when there was an error, there was a blank page, so that was a problem. And with that little addition, that at least was fixed. And now there is an actual throwable error, so they can react to it and show a good old, hey. Nothing works anymore, error page, which is, better than a blank page for sure.

Michael Thiessen:

Mhmm.

Alexander Lichter:

So it's also something which you as a user probably won't enable straightaway. That's more something maybe the the, like, Vike will enable that for you with the settings, or it's like, okay, if you wanna behavior, you can try it out. But when using Nuxt, you probably won't need it because there's a solution working already.

Michael Thiessen:

Yeah. So let's move from, like, the more bigger picture kind of global errors down to more fine grained errors where we can actually look at errors on the component level and handle them on the component level. So the benefit here is that we can have much more localized error messages and ways of recovering from those errors. So instead of your entire application, just kind of dying and throwing up a cat GIF, we can have, you know, like, some widget on the page doesn't load for whatever reason and that fails, but the rest of your app is still working fine and you can, you know, have, like, a a retry mechanism or something like that.

Alexander Lichter:

Exactly. I mean, it would be a a shame if you have, like, a big application, say, ecommerce, and you try, I don't know, to load your Wishlist, and the Wishlist microservice in the back end for whatever reason has a hiccup, and your whole application fails. So that would be a problem instead. You just don't say, hey. I can't load the wish list right now.

Alexander Lichter:

Try again or try later or whatsoever. So that's really that component level, let's say, error handling that's pretty neat. Also, one term that comes to my mind is graceful degradation there. So, like, okay, we have problems, but the mission critical systems are still running. So parts of our application might not work, but a big part is is still, good to go.

Alexander Lichter:

So there's definitely a pattern for bigger applications to embrace just to make sure they are a bit more resilient and, well, not that that brittle and just crash because maybe also some random third party who is like, nope. Doesn't work. Goodbye. So So definitely a pattern to adopt, and that's really the sweet spot between, like, these request based super, like, fine grained solutions, which you do if, like, a try catch or watching the error property. And, oh, everything is broken.

Alexander Lichter:

So if if you haven't built it into your application, that might be a good time to raise that with your team, or if you work alone, then bring it in.

Michael Thiessen:

Mhmm. Vue gives us this life cycle hook called on error captured, which basically is exactly what it sounds like. If you have this, you can capture the error and then do something with it. So it's effectively like this try catch, but for your component. And you can decide to return false, I believe, and then it will continue to, you know, throw the air and you can say, not gonna handle this one.

Michael Thiessen:

But it still lets you do some sort of handling on that. And one thing that's important to keep in mind, and the docs state this as well is that you have to make sure that when you catch that error, you don't reset, fix the error, but then immediately rerender the thing that caused the error because then you can get into this infinite loop of reset the error, throw an error, fix the error, throw an error back and forth and back and forth, and then, you know, that that's not really what you want, I don't think.

Alexander Lichter:

Hopefully not. Otherwise, well, you don't like your users that much. One tiny thing, I think, like, when you return false and on error captured, then it's a bit like the error won't bubble up further. It's just like, okay, it's handled, I think. So Okay.

Alexander Lichter:

Then then that should be fine. But, yeah, it's a really nice, functionality more and more people should use.

Alexander Lichter:

And if using Nuxt, then you might not even have to use it because then you can use the Nuxt Error boundary, which is more or less a wrapper around that on error captured hook. It's used under the hood. Then the Vue Error hook, which is a Nuxt hook, right, not the life cycle hook of Vue, is called with that error so the whole app knows about it if if you want to.

Alexander Lichter:

And there is this local error state. So it can even say, okay, if there's an error render, this fallback component. You can also do it in plain Vue. It's just a bit more effort, and you can do it on the client side. Of course, not a problem.

Alexander Lichter:

And you can even have, with a scope slot, that clear error method. So in your error component, you can say, hey. Let's retry it. Then you can clear the error, and we can continue the whole process. Of course, then if it fails again, the error slot is shown again, and you kinda avoid at least the problem of, like, that infinite loop because you have a a fallback component.

Michael Thiessen:

Yeah. I'd recommend you check out how this component is implemented. We have linked to it in the show notes as always. And it's like 30 lines of code, including all of the the Nuxt hooks and the SSR and hydration stuff that it's accounting for. So if you wanted to implement your own just in Vue for your own application so you can just, like, have this error boundary component, it's not too difficult to implement and to figure out what's going on there.

Alexander Lichter:

100%. Also recommended. It's a really nice pattern. And in the end, you'd build something like that anyway when you really use it to say, like, oh, I wanna render a fallback, and then you have it abstracted nicely. So, yeah, definitely worth worth a read.

Alexander Lichter:

And besides these two ways that are more or less the same one, a bit more abstracted in the the lower level, Vue has also a way for asynchronous components. So we talked about suspense in the last episode as well. You might also already use it if you await something in your component, no matter if you use Nuxt or or Vue. And if you define a component as an async component, which is more common in Vue because in Nuxt, you get the abstraction around it already. Right?

Alexander Lichter:

Then you can even say, okay. I'll pass in, like, a time out and then an error. So in case, I don't know, the API takes too long or even throws an error, as a Vue developer, I can show a component as, like, oh, that didn't work out. Here's my error component. So that's also a way only works, of course, for asynchronous components, but make sure that if the whole component doesn't load, then you have that fallback, which can be helpful.

Alexander Lichter:

By the way, same works also with a loading or, like, a placeholder component too.

Alexander Lichter:

And, yeah, then from there, we go already to a very, very, very fine grained level, which is, well, more or less the the request based situation. So I think most of us know that scenario. You send a form, right, like, some form data over to your back end, and then the classic thing, oh, validation error. Right?

Alexander Lichter:

Even though you do form validation in the front end, maybe that can differ and all that. So you get maybe back, 400, 42, or whatsoever, and you won't deal with that. So, of course, you don't wanna show a whole error page there because, well, the error is kinda clear. So, commonly, what you do, try catch, have some kind of error ref, and then you're good to go. You fill it up, then you have a way to clear that either automatically or when the next time you send things.

Alexander Lichter:

There are there are some patterns here that can be really nice because, like, error state is always a bit tricky, and run-in validation for the form is always like, should you validate forms straight away when your user's typing something? Should you do it after they leave the field and so on and so on? But the same idea with the back end validation, like, how long should the error stay? Should it be longer? Should it be for a couple seconds?

Alexander Lichter:

Personally, I'm always a friend of making that as expressive as possible. So just say like, oh, an error here's that that in that field, I can highlight the field, of course. That's that's a problem. And then say, try, basically, fix that and try again. And when they try again, hopefully, the error is gone.

Michael Thiessen:

Yeah. It's, always good to have, like, these extra try catches, not extra, but, like, around your requests and and things like that. You can also, like, with most fetching libraries have some error handling state with it. So if you're using ofetch, which I tend to use if I'm in the Nuxt world, I'll import ofetch, and it has, like, a nice little error thing you can check. I think Axios, it's been a while since I've used Axios, but

Alexander Lichter:

It has it too. Yeah.

Michael Thiessen:

It has it too where you can just oh, if error, then do this thing. And so if you get an error from the API, then you can handle it nicely.

Alexander Lichter:

Yeah. I mean, I think when you use the plain fetch API, so no wraparound, it's always like, oh, you have to check if the response is okay. And if not, then you fail. So if there's any network issues, you're still going to try catch, and you don't even get there and so on and so on. And, like, with Ophir, it's pretty nice because, yeah, try catch.

Alexander Lichter:

If the error is there, like, if that's the instance of that, go for it. So TypeScript is happy as well because, technically, you can just write throw 42 in your application. Please never do this. And and it will throw that, so we never know what actually comes comes out there. And, also, when it comes to validation, things like parses, right, like, Zod, valibot, and so on are immensely helpful, first of all, to make sure that the results are actually what you expect and also type safe.

Alexander Lichter:

And, of course, also to deal nicely with errors because then you have your schema and say, oh, that schema doesn't fit. Now you know exactly what the problem is. So that's, that's definitely a big plus there.

Michael Thiessen:

And, Yeah. In Nuxt, we do fetching with useFetch and useAsyncData, also dollar sign fetch. We covered that a little bit before. And, yeah, you get that error state out that you can check. I think recently, there was some updates on how the error was typed, I believe.

Michael Thiessen:

I I'm not I'm a little fuzzy on those details.

Alexander Lichter:

Yeah. For Nuxt four. Like, that's that's correct. Usually, like, you get data and error and, like, the state in general out of these composables. So you can say either data or error is filled because, well, you can't have both at the same time.

Alexander Lichter:

And then right now, like, it could be null or undefined. It's, like, nullish. And in in Nuxt 4, I think it's only null. I I also like it's always I don't know. I don't know if I'm but it's there's definitely one.

Alexander Lichter:

Check out the Nuxt 4 migration guide because you can opt into these things already if you're using Nuxt. That's definitely worth looking into. And, yeah, from there, you can decide, as I said before, like, you can watch the error, say, hey. Okay. This I wanna we throw, say, the component.

Alexander Lichter:

No. That doesn't work. Maybe I I just wanna change parameters. Maybe I just wanna log something, and it's it's okay. So you have all the full control.

Alexander Lichter:

And because just because a request fails, it doesn't mean that the component has to error. Same with, like, the form request. Right? Then it's totally fine to just log it out, and and you're good to go. But, yeah, besides that, I think error handling is something that a lot of developers don't really have, like, let's say, as their first priority, which I kinda get.

Alexander Lichter:

Like, you wanna make it work. You're going for the happy case. But especially when users come in and then, like, oh, they click on a wrong button or, like, a wrong order that it's not the happy path and then things crash. You really wanna make sure, first of all, that, like, you logged the error somewhere, you tracked them because maybe you never know. Maybe there's even a browser incompatibility thing you have never heard of.

Alexander Lichter:

And without a proper, error tracking tool, you you don't know because you're not using the browser. Right? Maybe you're just in your Chrome. And in Safari, things break. You never figure out maybe until your client calls.

Alexander Lichter:

You're angry. Like, hey. On my laptop, the shop doesn't work. What's with all my customers? And, yeah, you you really wanna avoid that.

Michael Thiessen:

Or, what happened with me, like, the first thing I pushed on my one job, and then I thought it was great, but then someone tweeted at the company that this thing was broken with a screenshot. And, Damn. Never never gonna never gonna forget that one.

Alexander Lichter:

Yeah. These are always, like, the scenarios where error handling, of course, keeps it super handy, but, of course, also the whole type of, like, okay, code reviewing, actually testing the feature and so on. So there are a lot of things going hand in hand, but especially, like, even if you don't have time for, like, an intensive test. If you don't have a test suite, you should add 1 for sure. But then at least error handling will it will tell you the problems before the people are sending screenshots to your company's Twitter or, like, calling your client and they call you angrily.

Alexander Lichter:

So that's always a way to be better better safe than sorry. Plus, a lot of these tools have really, really generous free tiers. And, for example, Sentry is also open source, giving me self hosted. So you're kinda good to go with that. Just make sure that's tracking everything and also that you track all these server side errors as well.

Alexander Lichter:

So if you use Nitro with an API, also worth to hook in there. There's also we can mention that too, a hook actually, our hook to make sure, okay, if there's any kind of problem, just log it out straight away. Make sure you ignore all the 404s maybe and maybe also the 400, 42s for validation stuff just because you probably don't want to have them logged in. Sometimes even people say, yeah, let's leave these in because if it happens so often, then maybe there's a problem with a form because, ideally, you have that in the front end. Right?

Alexander Lichter:

Or, like, the people are confused. So sometimes that could be good, at least for the validation part. So that's definitely also something to to keep track of if you're using SSR or if you also maintain an API to make sure you have the tracking on both sides because both are points of failure, so to say.

Michael Thiessen:

Yeah. And these tools, you can also often have, like, pretty good filtering of these. So if you want want to filter those out for the most part, you can set that up in your dashboard or whatever.

Alexander Lichter:

Exactly. And, yeah, I think that's a a really nice overview about what's possible when it comes to error handling in in Vue and in Nuxt, and a little bit in Nitro as well. We could probably also, like, dive deep into, like, oh, yeah. What's with Flexus, pens, errors? But we even covered that with the the error component there.

Alexander Lichter:

So if there's anything that you are maybe missing in the Vue ecosystem when it comes to errors, let us know. Write us a message, a comment somewhere on all social media platforms where, we are or DejaVue is at, and, we'll definitely read through them and answer. So really curious if there's something like, oh, this is a problem. We really need that. Yeah.

Alexander Lichter:

Maybe there's a maybe a solution out there.

Michael Thiessen:

Yeah. I think the the hardest part about handling errors is actually handling the errors. And it's not as much about, like, configuring it or putting in, like, try catches, but just remembering to do it, which is, you know, the same with, like, testing or accessibility or, like, all these other things that, like, can feel like extra things where you're, like, okay, I finished my feature, and

Alexander Lichter:

it's not,

Michael Thiessen:

like, wait. Wait. No. I have to, like, I'm only, like, you know, a third done. I've gotta do all these other things to, like, make it to actually finish it and and make it production ready.

Alexander Lichter:

But as you mentioned, like, yeah, a lot of these things are for us, like, extra as well. That should be part of it. And that should be part of your your sprint planning, thinking about it, like, estimating story points or feature points or whatever, your viewpoints, whatever you estimate. Because, like, it should be it should be part of it. Otherwise, you'll pay the cost later or your client will pay cost later.

Alexander Lichter:

The latter is always the worst, of course, because if you have to, in the end, okay, that might be a bit more, like, more hours, not too nice. But, yeah, if there's, like, business value that's, ruined, that that would that would suck big time. Yeah. So that's true. But you you won't believe how often I see it in applications when there is no error handling or just, like, a console log.

Alexander Lichter:

And same for accessibility. I've even, like, a review application recently where they still use, like, anchor tags with an hrefs set to a a money sign, like, hash, instead of, like, a button or, like, what? Why? What what there is a button element, and that's like the the 101 of semantic HTML.

Michael Thiessen:

Yeah. Buttons that look like links and links that look like buttons. I've seen both and,

Alexander Lichter:

Over, not a good idea. Have a component for that. Like, come on. Just add a component that can do both and then use that, especially for styling as well. Like, I actually same for headings and typography.

Alexander Lichter:

Right? Released a video on that, I think, 2 weeks ago when that's aired. So, like, just abstracted away. You never have to worry about it. It will just work and have all the stylings there, and you don't have 50 buttons that look all different.

Alexander Lichter:

So, yeah, that's, it's really helpful to do that. And then don't forget the error handling.

Michael Thiessen:

And that's it for this episode on error handling. I hope that you enjoyed it. And as always, check out the show notes for all the links and everything else. Check out previous episodes if you missed any. We've got a bunch of great people on, but your great topics that we've talked about, and we will see you next time.

Alexander Lichter:

Exactly. Until then, folks. See you.