Check out a free preview of the full Rust for TypeScript Developers course:
The "Error Handling" Lesson is part of the full, Rust for TypeScript Developers course featured in this preview video. Here's what you'd learn in this lesson:

ThePrimeagen introduces error handling and different strategies for addressing errors in an application. If a function throws an error, default values can be returned instead of the error with unwrap_or. The and_then method can also layer on scenarios for handling an error.

Get Unlimited Access Now

Transcript from the "Error Handling" Lesson

[00:00:00]
>> The question is to throw or not to throw. Can anyone name a very common function in JavaScript that throws? Right now, go. Come on, json.parse. Don't you know that it throws? Yeah, that's actually really dangerous, a lot of people forget to wrap their json.parse with the try catch because sometimes you don't get JSON and your whole server dies.

[00:00:24] Your dead, right? So you don't want that. So, that's a big thing about JavaScript, is when I ask that question, no one could really give me an answer because you just don't think about it that often. We already read file today, reading file control errors. Just sometimes you just don't process it, it's not there.

[00:00:40] Rust on the other hand, if there is a possibility of an error, you must specify it. It cannot operate any other way, that's the way it is. And here's the best part. Is that errors, they're enums, exact same thing. Again, we're just going over more enums at this point.

[00:00:57] And also it defeats this problem right here. So if you're a Go programmer at all, this is the one thing that is just a little bothersome about Go. That, well there's a few things, but this is one of them. You no longer have this meme, the meme is gone, you don't have to worry about it.

[00:01:11] And so here's the definition of result. Does this make sense everybody? I think this should make sense. You have two generics, you have your value type and your error type. And your two enum values, which is an Ok of value type, or Err with subtype error type. Makes a lot of sense.

[00:01:28] And also Ok slash Err are first class citizens, meaning I can jump in here and go, let foo = Ok (5), right? And if you look at this, it's gonna say, hey, this thing's a result and unknown. So you have to be a little bit more verbose on your typing because it needs to know both type of errors.

[00:01:47] Right now I'm just doing this right here, it just makes it so dang easy. So let's kind of go over that a little bit. I'm just gonna kind of give you a quick swift one because you've already seen these, right? So, this should be completely understandable at this point.

[00:02:00] If let pattern match the Ok, get the inner value out of this. This function may throw an error, so if this function returns an error, we just ignore it. It did not meet our pattern matching, we just move on. You can do a match statement, meaning that we have a branch that handles the value, we have a branch that handles the error.

[00:02:17] Again, just pattern matching on the enum types. This value being the V, this value being the E. So, again, you can also just completely ignore it. In Rust if you call a function that could error and you don't do anything with that error, it's gonna give you a warning.

[00:02:32] It's gonna say, hey, by the way, you're returning a result type, but you're not doing anything with it, could be important. So, just assigning it to underscore says, I don't care. I'm always a little hesitant doing this specifically in async programming cuz when it comes to async, you return futures and futures come with the same warning.

[00:02:52] Warn on unused, you can actually define any structure warn on unused and it will warn you your code. And if you assign it to underscore and then it becomes async, you won't use the async future and futures have to be awaited for them to execute. And they'll be, why is my code not executing?

[00:03:10] You assign it to underscore. So always be careful about the underscore. You can always yellow your error with unwrap. You can respectfully yellow it with expect. So expect just says, hey, this thing should not error, but if it does, here's the message, crash my program, this should not happen.

[00:03:24] You can do default unwrap or, so just like options, it also has unwrap or. It has unwrap, it has unwrap or with a function, it has a bunch of stuff. You can even convert a result into an option by calling Ok. This will take the Ok value and turn it into some value.

[00:03:43] It'll take the Err and just turn it into nothing. We only care about positive values, we don't care about any errors. So you can kind of convert between them very easily. You can also map them, so if you want to map over the underlying value type, we can map.

[00:03:59] We can even do and thens. So and then, so if we wanna do a function that could error, and then a function that could error, and then a function that could error, the and thens only get executed per successful step. So we could have this nice kind of way to chain a bunch of erring operations together.

[00:04:14] You can also do the question mark operator. So, if your function returns a result that has the same error type, just like with option, you can just question mark and boom, you get the inner value out of the okay side. But if it's an error, we return the error.

[00:04:30] So it's kind of this really nice syntax, is effectively if error does not equal nil return return error. It's like Go but in a shortcuted version of it. And of course, there's two crates that are super useful. So if you ever decide to start using Rust and you start developing your own library, check out this error.

[00:04:45] It's just a really nice way to be able to have the error interface, but you could kind of define it and have your exact errors you wanna do with nice text to it and all that. Or anyhow which is just completely willy Nelly, it's crazy how easy it is to use and you use this an application code largely.

[00:05:03] That's kind of how you think about, so you wouldn't wanna use anyhow in a library, you'd want to use anyhow on an application. That's generally what I've heard. Things may have changed, maybe new opinions have emerged, but that's been my general take on it.