On Error Handling in Rust

Post by masklinn » Fri, Oct 17, 2014, 5:37 PM UTC

mhaymo wrote: post #59

benjaminjackman wrote: post #34

Earlier quoted context omitted.

I agree, I could not write it better myself. Going down one level and finding a better way to express the sugar around `map` and `flatmap` on Monads (and then `withFilter` in Scala) without resorting to compiler magic would be really cool and would let programmers add their own constructs that operate on a lot more than monads. Out of curiosity, do you know of another language that has something on the level of Resul…

Is Result not just a specialised Either? In what way is Either inferior?

    fn main() {
        f1();
    }

    fn f1() -> Result {
        Ok(())
    }

    > rustc test.rs
    test.rs:2:5: 2:10 warning: unused result which must be used, #[warn(unused_must_use)] on by default
    test.rs:2     f1();
                  ^~~~~

Post by benjaminjackman » Fri, Oct 17, 2014, 5:44 PM UTC

comex wrote: post #61

benjaminjackman wrote: post #60

Earlier quoted context omitted.

Oh ok that makes sense. Either has a little more to it, as I am sure you are aware, specifically Type Disjunction, but a crappy version of Result is all anyone ever really uses it for as far as I have seen. Real quick for those that don't understand, when I say Type Disjunctions (aka union types) I mean a type which has a value which the type system is guaranteeing is 1 of X different types. So Either[String,Int] is…

Rust has always supported type disjunctions :) Result is simply defined as pub enum Result { Ok(T), Err(E), } where enum is a general 'variant type' mechanism. (Nor is Rust a fan of type hierarchies in general - it doesn't even have subclassing.)

  pub enum ParseResult {
    ParseError(Err) 
    IntResult(Int)
    StringResult(String)
  }
  def parse : ParseResult

  newtype ParseError = Err
  def parse : ParseError | Int | String = ...

  pub tuple MapEntry {
    Key(K)
    Value(V)
  }
  class SortedMap {
    def firstEntry() : Option>
  }

  class Map {
    def firstEntry() : Option
  }

Post by Jweb_Guru » Fri, Oct 17, 2014, 6:23 PM UTC

comex wrote: post #65

benjaminjackman wrote: post #64

Earlier quoted context omitted.

Oh well I guess I will have to read up on rust some more then before writing long winded posts :) That's very cool. Does it allow inline type disjunction declarations? Rather than (never written rust before) something like: pub enum ParseResult { ParseError(Err) IntResult(Int) StringResult(String) } def parse : ParseResult Allowing something like this newtype ParseError = Err def parse : ParseError | Int | String = .…

No, it doesn't. I think this is the right choice, because when unpacking you need some way to distinguish them anyway, i.e. in match foo { ParseError(e) => ... IntResult(i) => ... StringResult(s) => ... } you need something adorning the left to determine what 'e', 'i', and 's' are; you could use the type, but compared to that it doesn't save much typing to just name the branches (which can always be abbreviated), whi…

Post by benjaminjackman » Fri, Oct 17, 2014, 6:45 PM UTC

comex wrote: post #65

benjaminjackman wrote: post #64

Earlier quoted context omitted.

Oh well I guess I will have to read up on rust some more then before writing long winded posts :) That's very cool. Does it allow inline type disjunction declarations? Rather than (never written rust before) something like: pub enum ParseResult { ParseError(Err) IntResult(Int) StringResult(String) } def parse : ParseResult Allowing something like this newtype ParseError = Err def parse : ParseError | Int | String = .…

No, it doesn't. I think this is the right choice, because when unpacking you need some way to distinguish them anyway, i.e. in match foo { ParseError(e) => ... IntResult(i) => ... StringResult(s) => ... } you need something adorning the left to determine what 'e', 'i', and 's' are; you could use the type, but compared to that it doesn't save much typing to just name the branches (which can always be abbreviated), whi…

  //Sorry for the Scala-ness
  //Presume a mapByType partial function on all discriminated unions if the union value is of that type, then it calls
  //the partial function otherwise it just returns whatever it's current value is
  def lexAndParse : ParseError | LexError | Int | String = lex().mapByType{ case t : Token => parse(t) }
  newtype LexError = Err
  def lex() : LexError | Token = ...

  newtype ParseError = Err
  def parse(t : Token) :  ParseError | Int | String = {
      tryParseInt(t).orElse(tryParseString(t)).getOrElse(ParseError("$t not Int Or String"))) }
    }
  def tryParseInt(token : Token) : Option[Int] = ...
  def tryParseString(token : Token) : Option[String] = ...

  pub enum LexParseResult {
    LexError(Err) 
    ParseError(Err) 
    IntResult(Int)
    StringResult(String)
  }
  def lexAndParse : LexAndParseResult = {
    match lex() {
      LexResult.LexError(e) => LexAndParseResult.LexError(e)
      LexResult.TokenResult(t) => match parse(t) {
         ParseResult.ParseError(e) => LexParseResult.ParseError(e)
         ParseResult.IntResult(e) => LexParseResult.IntResult(e)
         ParseResult.StringResult(e) => LexParseResult.StringResult(e)
      }
    }
  }

  pub enum LexResult {
    LexError(Err) 
    TokenResult(Token)
  }
  def lex : LexResult

  pub enum ParseResult {
    ParseError(Err) 
    IntResult(Int)
    StringResult(String)
  }
  def parse(token : Token) : ParseResult = {
     match lex(){
       Token(t) => 
        tryParseInt(t).map(r=>ParseResult.IntResult(r)).orElse(tryParseString.map(r=>ParseResult.StringResult(r) )).getOrElse(ParseResult.ParseError("$t not Int Or String"))) }
       LexError(e) =>  ParseResult.LexError(e)
    }
  }
  def tryParseInt(token : Token) : Option[Int] = ...
  def tryParseString(token : Token) : Option[String] = ...

Post by lmm » Fri, Oct 17, 2014, 7:13 PM UTC

kibwen wrote: post #58

lmm wrote: post #57

Earlier quoted context omitted.

`Carrier` is still pretty parochial; it has this normal/exception distinction hardwired into it, no? The RFC explicitly rules out using Vector with it, and it doesn't look possible to implement for async constructs, or STM transactions, or the like? I'd very much like to be wrong here. FromError is not handled specially by the compiler, but it is handled specially by the try macro; does the signature of try make the…

> `Carrier` is still pretty parochial; it has this > normal/exception distinction hardwired into it, no? To reiterate my earlier point, I'm personally fine with the existence of an entirely separate mechanism for error handling. Mind you, not that this invalidates your desire for a more general mechanism for async et al. Until/if we get HKTs, we'll probably continue to achieve this with bespoke macros as per today's…