5 ms·
Fundamentally, the argument is that error handling in C is bad. That's both a language and a library problem.
by cbarrick 5y ago
Fundamentally, the argument is that error handling in C is bad. That's both a language and a library problem.
- Someone 5y agoI don’t see that in this post. errno is a library (mis)feature. Rust’s if let Ok(my_number: u8) = &my_number_string.parse() { assert_eq!(my_number, 42); } could, in C, look like this: if(parseInt(my_number_string, &my_number)) { assert(my_number == 42); } That’s fairly similar, and the article doesn’t claim Rust is bad, or that C is bad because it doesn’t support multiple return values or restructuring (which could be used in place of it to make a function returning a struct look as if returns multiple values) (aside: u8 is not the type I would have chosen in that Rust example)
- duped 5y agoThe semantics are very different, even if the syntactic results are superficially similar. In Rust you cannot retrieve the value on success without explicitly handling the error - that's forbidden by the type system. Additionally you can't have an unitialized error result, or force the callee to check the argument for null. I think the example is pretty weak, because the difference isn't that meaningful in an isolated case. Consider something like parsing an HTTP request - it is difficult to even write the toy example without handling the major error cases. The result is a robust program by default.
- petmon 5y agoRust sometimes throws away errors when they would be awkward to handle - close() in Drop and println!() are important examples. A Hello World with a closed stdout will correctly fail in C but "succeed" in Rust because it ignores EBADF. https://github.com/rust-lang/rfcs/pull/1014 https://github.com/rust-lang/rfcs/pull/1014