Don’t panic! Learn to build quality software resilient to errors. In this story, we discuss methods for panic resilience in Rust applications, to make quality software users can rely upon. By Luke I. Wilson.
If you consider your software a car driving at about 60 miles per hour, a panic is like hitting a brick wall.
Some newer languages designed after C use exceptions for error handling, which is a high-level abstraction to error codes. Calling a function which may fail and cause an exception requires a try and catch block – to execute code that may cause an exception, and to handle the error signaled by the exception. Exceptions are still not always explicitly handled, and thus some lazy programmers handle exceptions the same way as .unwrap() handles errors in Rust — print the error and fail.
A crash is not ever “appropriate” behavior, but it’s better than allowing your system to cause physical damage. If at any time it may be believed that the software could cause something deadly, expensive, or destructive to happen, it’s probably best to shut it down.
The article looks at three crucial sections about handling errors in Rust:
- When to Panic,
- Handling Errors,
- And the additional section: Error Handling in a Library.
It is always better to exit with an error code than to panic. In the best situation, no software you write will ever panic. A panic is a controlled crash, and must be avoided to build reliable software. Rust empowers anyone to build highly robust, reliable, and efficient software. So don’t panic! Use the correct methods for writing reliable software with Rust. You will get links to further reading and example code to explain points mentioned in article. Well done!
[Read More]