PostHole
Compose
Login
SE Radio 644: Tim McNamara on Error Handling in Rust
Tim McNamara, a well-known Rust educator, author of Rust in Action (Manning), and a recipient of a Rust Foundation Fellowship in 2023, speaks with SE Radio host Gavin Henry about error handling in Rust. They discuss the errors that Rust prevents, what an error is in Rust, what Tim classes as the "four levels of error handling," and the lifecycle of your journey reaching for them. McNamara explains why Rust handles errors as it does, how it differs from other languages, and what the developer experience is like in dealing with Rust errors. He advocates best practices for error handling, what Result is, the power of Rust Enums, what the question mark operator is, when to unwrap, what Box really means, how to deal with errors across the FFI boundary, and the various Rust error-handling crates that you can use to give you more control. Brought to you by IEEE Computer Society and IEEE Software magazine.
Tim McNamara, a well-known Rust educator, author of Rust in Action (Manning), and a recipient of a Rust Foundation Fellowship in 2023, speaks with SE Radio host Gavin Henry about error handling in Rust. They discuss the errors that Rust prevents, what an error is in Rust, what Tim classes as the “four levels of error handling,” and the lifecycle of your journey reaching for them. McNamara explains why Rust handles errors as it does, how it differs from other languages, and what the developer experience is like in dealing with Rust errors. He advocates best practices for error handling, what Result<T> is, the power of Rust Enums, what the question mark operator is, when to unwrap, what Box<dyn std::error::Error> really means, how to deal with errors across the FFI boundary, and the various Rust error-handling crates that you can use to give you more control. Brought to you by IEEE Computer Society and IEEE Software magazine.
Show Notes
Related Episodes
Other References
- “Understanding and Detecting Real-World Safety Issues in Rust,” IEEE Transactions on Software Engineering
Transcript
Transcript brought to you by IEEE Software magazine and IEEE Computer Society. This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number.
Gavin Henry 00:00:18 Welcome to Software Engineering Radio. I’m your host Gavin Henry. And today my guest is Tim McNamara. Tim is a well-known Rust educator. He wrote the book Rust in Action and received a Rust Foundation Fellowship 2023 in recognition of his efforts remote language. He also runs Accelerant.dev, a consultancy focused on the Rust programming language. Tim hosts a YouTube channel podcast and is active on most social media platforms as Timclicks. Tim, welcome back to Software Engineering Radio. We last spoke in 2021. Is there anything I missed in your bio that you’d like to add?
Tim McNamara 00:00:58 No, no. Thank you very much for the introduction.
Gavin Henry 00:01:01 No problem at all. Okay, so today the show is talking about Rust error handling and Rust. So I really enjoyed your talk for Rust Nation UK, which is about Rust Errors. So I thought I’d like to get you on the show again because it really helped me understand them. So I think it’ll be great for our listeners to not only explore errors and software and bugs in general, but how Rust helps us with them to avoid them and give us the flexibility to do what we need to do.
Tim McNamara 00:01:33 Well look, it’s a pleasure.
Gavin Henry 00:01:35 So I want to lay the foundation before we move into what you called the four levels of errors in Rust for that talk you did for Rust Nation UK. So let’s start bit of a high level one. What is an error?
Tim McNamara 00:01:52 This is a deceptively difficult question to answer. That’s probably why you’re starting with it because there are almost 2D, well there are multiple different, right? So if we think of, let’s just say that we have, we think of a simple program as started going through some a series of instructions and then terminating. An error we could define it as essentially at one of those steps, some input it receives something that it does not understand or does not expect and so, or there is some precondition that isn’t satisfied and then the program cannot continue to the next step. Essentially you can think of an error as a fork in the control flow and error handling as being a way to essentially split the program apart and down the happy path let’s say. Or the main path is the control flow that you sort of intended and down all of these error paths, which also could be used, we could use the term exceptional paths.
Tim McNamara 00:03:05 Which kind of hinted the name of exceptions are smaller, less likely cases which we have thought about beforehand as programmers of essentially ways of dealing with problems that we expect that we might encounter. For example, I talked about input and I meant that in a very general sense, but if you are a web framework, you expect that people will send you all sorts of nonsense from the network. And so your web framework should deal with input that does not satisfy let’s say HTTP or, and the definition essentially of what is valid input and what is invalid input sort of slightly changes at each step. But the other side of what an error might be is something that is completely unexpected or the program might encounter a state in which it’s impossible to continue down any path. And the typical response, most programs at that stage will be to just crash. The operating system will just kind of close everything down, close all of its files, shut down all of its network sockets, free all the RAM and essentially ask the user to restart the program. And the way that I think of errors is to think of them as a sort of forks in the road or from what we intend or expect.
Gavin Henry 00:04:36 Perfect. And with something like a program or a Rust in particular, assuming that’s an input is a certain thing that could also be covered by what you’re saying, where the inputs are wrong as in and dynamically type languages you’re assuming it’s something but it’s not.
Tim McNamara 00:04:56 Right. We have more inputs than just the data itself so that every block or every statement or every expression essentially has some extra material like the data type that it expects. And if you pass a string into a function which is really trying to do perform mathematical operations, you’ll likely to have a very bad time. Perhaps not if you, although there are some languages which have essentially said that our approach is to just accept that and do the best that we can irrespective of the input. And so my understanding of Pearl for example is that if you pass in a string to a function that accepts something numeric and it uses ESKY literals, so essentially you have numerals in the string or at the start of the string, then Pearl will just accept that as a number itself. And so there are huge philosophies essentially of software and what is acceptable or permissive in a large spectrum.
[...]