unwrap
unwrap
unwrap
unwrap already
I hate Rust soooo much.
Quotes means its a string. Why then do I need to_string? lol.
If I already said listen or timeout, why do I need to also say LISTEN and TIMEOUT? Is the compiler deaf?
If almost everything needs a &, maybe that should be the default sometimes?
Rust has a myriad of ways to handle errors, and unwrap is the most blunt of those instruments as it explicitly converts handleable errors into panics.
Alternatives such as try!, unwrap_or(), and many others, should be your preferred options. I try to only use unwrap() in throwaway code and usually only in main functions.
The one thing rust doesn't let you do (at least without warnings), is to have unhandled errors.
Being forced to explicitly handle error conditions is a huge net win for any production code.
Sounds a bit like Java's checked exceptions, largely regarded as a failed experiment. What makes Rust's version better?
I think the key difference between checked exceptions and Rust's monadic error handling is that it's very easy to just panic if you don't care about recovering from the error. In Java you have to write "try { ... } catch (IOException e) { throw new RuntimeException(e); }", which is very verbose, and it's a lot less code to just ignore the exception. In Rust it's just ".unwrap()".
The whole thing is asinine. Its the worst part of programmer culture.
Question 2: no, you don't use unwrap in production.
fn foo() -> Result<(),Error> {
// Create an event loop
let mut event_loop = try!(EventLoop::<(), u64>::new());
let sender = event_loop.channel();
for i in 0.. 5 {
try!(sender.send(i));
}
// Start it
try!(event_loop.run(&mut BearHandler(0));
}In "real" Rust code we have several ways of dealing with possible errors and "None" results.
`.to_string()` tells the compiler to use a `String` which owns it's memory instead of a `&str` which is doesn't own it's...
Oh wait, reading your comment you're trolling.
The language will be refined as its strengths and weaknesses are exposed.