3 ms·

I understand exactly what "?" does, I just don't want to have to type it every time I call a function that can fail. Additionally I don't want to have to distin

by softc 10y ago

I understand exactly what "?" does, I just don't want to have to type it every time I call a function that can fail. Additionally I don't want to have to distinguish between which functions fail and which don't, I'd rather assume all functions fail and make sure my code is robust enough to handle failure at any point. This is my preference. C++ is more efficient at error handling than Rust. In the common case of no error happening, Rust must check a return code, but C++ doesn't have to because of how exceptions are implemented in the Itanium ABI "zero-cost exceptions".

mmstick 10y ago
There is no cost associated with Result/Option when no error is returned. The compiler is smart enough to understand when failure is not an option. Only when an error occurs does Rust act on it. Additionally, it's nonsense to state that you don't want to handle errors when they occur, but want to write software that can handle failures at any point. Software libraries should handle their errors properly in the event that an error is possible in a function so that users of that library can handle them. Binary applications should handle errors when they occur versus randomly throwing them into the air and hoping for the best. The `?` operator is highly convenient in handling errors wherever they may occur whereby the error needs to be handled. You do not have to use the `?` operator if have other means of handling the error. In example, maybe you want to use a default value in the event of a failure: let value = attempt_value().unwrap_or(default); Or maybe you want to keep trying until it succeeds: let value = loop { if let Some(value) = attempt_value() { break value } thread:sleep(Duration::from_millis(1)); }; It's up to you how you handle your errors. The Option and Result types have a lot of methods for handling, such as and_then and or.
- softc 10y ago
  Hmm no. Rust always issues a compare instruction after a function call to verify if it was successful or not. In a function that can fail depending on runtime conditions, the compiler is unable to elide such a check. Also I don't think my error handling method is nonsense as it seems to work for all the code I write. If I don't handle an error at local function scope, my intent is to handle it higher up the stack.
- dbaupp 10y ago
  You're being too enthusiastic/wrong: there is a cost to Result and Option even in the good case. There still has to be a branch to check if there actually was no error. Result and Option are similar to error codes in C and have a similar cost/benefit trade-off, although of course with all the ADT/type-safety goodness.

by softc 10y ago

mmstick 10y ago

There is no cost associated with Result/Option when no error is returned. The compiler is smart enough to understand when failure is not an option. Only when an error occurs does Rust act on it. Additionally, it's nonsense to state that you don't want to handle errors when they occur, but want to write software that can handle failures at any point. Software libraries should handle their errors properly in the event that an error is possible in a function so that users of that library can handle them. Binary applications should handle errors when they occur versus randomly throwing them into the air and hoping for the best. The `?` operator is highly convenient in handling errors wherever they may occur whereby the error needs to be handled. You do not have to use the `?` operator if have other means of handling the error. In example, maybe you want to use a default value in the event of a failure: let value = attempt_value().unwrap_or(default); Or maybe you want to keep trying until it succeeds: let value = loop { if let Some(value) = attempt_value() { break value } thread:sleep(Duration::from_millis(1)); }; It's up to you how you handle your errors. The Option and Result types have a lot of methods for handling, such as and_then and or.

softc 10y ago
Hmm no. Rust always issues a compare instruction after a function call to verify if it was successful or not. In a function that can fail depending on runtime conditions, the compiler is unable to elide such a check. Also I don't think my error handling method is nonsense as it seems to work for all the code I write. If I don't handle an error at local function scope, my intent is to handle it higher up the stack.
dbaupp 10y ago
You're being too enthusiastic/wrong: there is a cost to Result and Option even in the good case. There still has to be a branch to check if there actually was no error. Result and Option are similar to error codes in C and have a similar cost/benefit trade-off, although of course with all the ADT/type-safety goodness.