161–170 of 197 posts
Earlier quoted context omitted.
The problem is that a function cannot know whether or not the caller can recover from a particular error, so there's no point in making that distinction in the first place.
It's part of your API design, if they are recoverable or not. You should lean towards recoverable: if the caller can't recover, they can always do something with it. But some kinds of problems are non-recoverable.
Earlier quoted context omitted.
I understand the anger but at the same time I don't. Overall unwrap() isn't good. Really it should be replaced by TODO WRITE ERROR HANDLING in 90% of its cases. That being said there are still good uses for it. The main _safe_ use for unwrap() I find is when dealing with an iterator of Results/Options (which seems to happen a lot). The pattern: .filter( |x| x.is_some() ) .map( |x| x.unwrap() ) Is safe, and I really d…
I'm not angry. > Really it should be replaced by TODO WRITE ERROR HANDLING in 90% of its cases. That's what the Rust community reads it as, mostly. I've seen it occur very infrequently in libraries (aside from example/benchmark/test/mocking code, of course). When it does its usually for really out of whack errors like poisoned mutexes, crashed threads, etc (mind you, these are for unwrapping error values, not options…
Thanks :D
I've been really struggling to get iterators in rust. I don't have a very strong functional background :|
Earlier quoted context omitted.
It's part of your API design, if they are recoverable or not. You should lean towards recoverable: if the caller can't recover, they can always do something with it. But some kinds of problems are non-recoverable.
Can you name one such unconditionally unrecoverable problem?
Using assert! to verify that your state is consistent is useful, in case you have a bug. But since it's all internal, it's not something that the caller can really recover from, either. It's not their fault, it's yours.
Earlier quoted context omitted.
I'm not angry. > Really it should be replaced by TODO WRITE ERROR HANDLING in 90% of its cases. That's what the Rust community reads it as, mostly. I've seen it occur very infrequently in libraries (aside from example/benchmark/test/mocking code, of course). When it does its usually for really out of whack errors like poisoned mutexes, crashed threads, etc (mind you, these are for unwrapping error values, not options…
> filter_map(|x| foo(x)) Thanks :D I've been really struggling to get iterators in rust. I don't have a very strong functional background :|
Earlier quoted context omitted.
This seems a bit too unpragmatic. Would you also require the user to explicitly handle: * Index out of bounds on every array op * Integer overflow on every arithmetic op * OOM on every allocating op Maybe if you're writing an ironclad RTOS for a critical system without any good redundancy? Otherwise these are such pervasive operations that most have accepted that they're not worth handling everywhere they happen. Req…
>Requiring that really dilutes the value/meaning of errors. No. You have already diluted the meaning of errors, and you want them elevated to _your_ standard. >Index out of bounds on every array op These are removed if you build a rust program with --release. >Integer overflow on every arithmetic op Add the Wrapping class if you expect overflow. Overflow _shouldnt_ normally happen on an Integer operation. It is a har…
Earlier quoted context omitted.
The author is missing the point. Is he? The point is that in Java you are still able to treat x unsafely, while languages with stronger typing do not. E.g. in Haskell, if a function returns a Maybe a , it will always be a Just a or Nothing value. Moreover, such languages allow you to make non-exhaustive matching against all constructors a compiler error. tl;dr: Haskell, Rust, et al. put the burden on the compiler. Ja…
>tl;dr: Haskell, Rust, et al. put the burden on the compiler. Java puts the burden to ensure safety on the programmer. (As can be witnessed in your snippet.) Actually, (much to my disappointment as I'm just learning rust) you can just take an Option or Result and .unwrap() and the compiler won't complain at you for not checking it. For such a "safe" strongly-typed language, I'm surprised that so much new rust code do…
> much to my disappointment as I'm just learning rust
Both languages discourage the use of these constructs, but they exist for good reasons.
Earlier quoted context omitted.
>tl;dr: Haskell, Rust, et al. put the burden on the compiler. Java puts the burden to ensure safety on the programmer. (As can be witnessed in your snippet.) Actually, (much to my disappointment as I'm just learning rust) you can just take an Option or Result and .unwrap() and the compiler won't complain at you for not checking it. For such a "safe" strongly-typed language, I'm surprised that so much new rust code do…
I completely agree. unwrap() is a huge mistake in Rust. There are brilliant ideas implemented in Rust (primarily the borrow checker) but their advantages seem to be wiped out by the kludge of unwrap.
(Not to mention that `unwrap` in no way subverts memory safety, which makes mentioning it in the same breath as the borrow checker puzzling.)
Earlier quoted context omitted.
I'm not angry. > Really it should be replaced by TODO WRITE ERROR HANDLING in 90% of its cases. That's what the Rust community reads it as, mostly. I've seen it occur very infrequently in libraries (aside from example/benchmark/test/mocking code, of course). When it does its usually for really out of whack errors like poisoned mutexes, crashed threads, etc (mind you, these are for unwrapping error values, not options…
> filter_map(|x| foo(x)) Thanks :D I've been really struggling to get iterators in rust. I don't have a very strong functional background :|
So `filter_map(|x| foo(x))` can be written more simply as just `filter_map(foo)`.
Earlier quoted context omitted.
> A programmer looking at the code for the first time will know, just by looking at the return type, "Hey, this method may not return a record! I'll have to handle that scenario." Well, that's basically the same thing with any nullable return then. Wether I return T or Optional , there might be no record. Even worse, when I return T, you only have 2 cases : I return something, or I return null. With optional, you hav…
You should never have to check that the Optional itself is null. While that is allowed by the language, it is such an obvious error that static analysis tools could easily detect it.
Earlier quoted context omitted.
> That said, it's pretty rare to need exactly 0 or 1 of something. That's interesting and sort of hard to agree with. I think uniqueness is very often desirable and very often paired with a lack of certainty about existence. "Does a user with this identity exist?" certain is handled properly as a 0-or-1 question, e.g..
Is your method "getUserIfItExists(username)" or "doesUserExist(username)"?
Another word I use a lot is "lookup".