7 ms·
> ?ing Errors and never actually handling them is just a terrible practice. This isn't true. It really depends. fn main() -> anyhow::Result<()> { can be
by steveklabnik 2y ago
> ?ing Errors and never actually handling them is just a terrible practice.
This isn't true. It really depends.
fn main() -> anyhow::Result<()> {
can be perfectly good, depending on your needs.
What Rust does with error handling is give you flexibility. It's true that means you can make a mess. I myself have a TODO on my current codebase where I'm not exactly happy with what I'm doing at the moment overall. But it can also be very elegant, and more importantly, it doesn't force you into one paradigm that many not be good for your needs, but allows you to decide, which is very important in Rust's conceptual space. I wouldn't want to be forced to use the above signature in a no_std context, for example.
- constantcrying 2y ago>can be perfectly good, depending on your needs. This gives the error to the calling process though. In some sense that means it is handled. I don't think I disagree though, but I think my point still stands. If you do not think about at what point your errors are actually resolved then your program does not have proper error handling. If you unwrap in the middle of your code, you have to accept that crashing there is a possibility, even from an error far away.