3 ms·

Oh, and added thing that bugged me a lot: The error part of Result<T, E>. During my short time of coding Rust (I'll get back to it later), I never really found

Oh, and added thing that bugged me a lot: The error part of Result<T, E>. During my short time of coding Rust (I'll get back to it later), I never really found a way to ergonomically handle errors. I find it really awkward that the error is a concrete type, making it so that you must convert all errors to "rethrow". Go's error interface, and even exception inheritance seems to have lower friction than this.

retrocat 9y ago
I'm quite fond of error-chain (https://github.com/rust-lang-nursery/error-chain https://github.com/rust-lang-nursery/error-chain), which helps mitigate it somewhat. You can do things like: use error::{Error, ErrorKind, Result, ResultExt}; fn some_func(v: &str) -> Result<u32> { v.parse::<u32>().chain_err(|| ErrorKind::ParseIntError) } The purpose of `chain_err` here is to add on top of the previous error, to explain what you were trying to do, instead of passing up the previous error (in this case, `std::num::ParseIntError`). If you don't like that, you can do something like this: use std::boxed::Box; use std::error::Error; fn some_func(v: &str) -> Result<u32, Box<Error>> { v.parse::<u32>().map_err(|e| Box::new(e)) } But then you'd have to box every error.
steveklabnik 9y ago
? should help a lot with this, but libraries like error-chain, or the newer (and, IMO much better) failure can help even more.
- arghwhat 9y ago
  But ? only worked if the function it was used in had the same error type as the function you called, which was mostly not the case... ... I think. I don't remember it that vividly.
  - foldr 9y ago
    It doesn't have to be the same type, there just has to be a suitable implementation of the 'From' trait to perform the conversion if the types don't match.
  - steveklabnik 9y ago
    ? calls a conversion function. It only won't work if the error you're trying to return won't convert to the error that's in the type signature. Even then, you have options, like .map_err.
    - arghwhat 9y ago
      We have gone a bit down a tangent here. My original complaint was about the friction of different error types compared to other languages (like, say, Go). Having to implement a bunch of From traits (unless you need io::Error, because everything seemed to have conversions from/to that), or having to implement inline error conversion through map_err, is such friction. I might go as far as consider it the most cumbersome error system I have used. Clean idea, cumbersome implementation. My comment about '?' not working with mismatched types was mostly just to say that it doesn't fix anything, it just adds a bit of convenient syntactic sugar.
      - xfer 9y ago
        There is zero friction if you use either error_chain/failure crate and you can still recover the precise underlying errors. The only thing is it allocates.
        red75prime 9y ago
        failure has no_std feature for the no-heap cases.
        arghwhat 9y ago
        I will look into those crates next time!

retrocat 9y ago

I'm quite fond of error-chain (https://github.com/rust-lang-nursery/error-chain https://github.com/rust-lang-nursery/error-chain), which helps mitigate it somewhat. You can do things like: use error::{Error, ErrorKind, Result, ResultExt}; fn some_func(v: &str) -> Result<u32> { v.parse::<u32>().chain_err(|| ErrorKind::ParseIntError) } The purpose of `chain_err` here is to add on top of the previous error, to explain what you were trying to do, instead of passing up the previous error (in this case, `std::num::ParseIntError`). If you don't like that, you can do something like this: use std::boxed::Box; use std::error::Error; fn some_func(v: &str) -> Result<u32, Box<Error>> { v.parse::<u32>().map_err(|e| Box::new(e)) } But then you'd have to box every error.

steveklabnik 9y ago

? should help a lot with this, but libraries like error-chain, or the newer (and, IMO much better) failure can help even more.

arghwhat 9y ago
But ? only worked if the function it was used in had the same error type as the function you called, which was mostly not the case... ... I think. I don't remember it that vividly.
- foldr 9y ago
  It doesn't have to be the same type, there just has to be a suitable implementation of the 'From' trait to perform the conversion if the types don't match.
- steveklabnik 9y ago
  ? calls a conversion function. It only won't work if the error you're trying to return won't convert to the error that's in the type signature. Even then, you have options, like .map_err.
  - arghwhat 9y ago
    We have gone a bit down a tangent here. My original complaint was about the friction of different error types compared to other languages (like, say, Go). Having to implement a bunch of From traits (unless you need io::Error, because everything seemed to have conversions from/to that), or having to implement inline error conversion through map_err, is such friction. I might go as far as consider it the most cumbersome error system I have used. Clean idea, cumbersome implementation. My comment about '?' not working with mismatched types was mostly just to say that it doesn't fix anything, it just adds a bit of convenient syntactic sugar.
    - xfer 9y ago
      There is zero friction if you use either error_chain/failure crate and you can still recover the precise underlying errors. The only thing is it allocates.
      - red75prime 9y ago
        failure has no_std feature for the no-heap cases.
      - arghwhat 9y ago
        I will look into those crates next time!