Announcing Rust 1.13

https://blog.rust-lang.org/2016/11/10/Rust-1.13.html

by Manishearth • 10 years ago

321 227 10 years ago

Perceptes2• 10 years ago

Congrats to the team and thank you! As always, my Docker image for Rust has been updated for 1.13: https://hub.docker.com/r/jimmycuadra/rust/

Scaevolus2• 10 years ago

The ? operator looks lovely. It's like the C# null conditional operator, but for the Result pattern:

    try!(try!(try!(foo()).bar()).baz())

Becomes

    foo()?.bar()?.baz()?

Versus the Go equivalent:

    a, err := foo()
    if err != nil {
        return nil, err 
    }
    b, err := a.bar()
    if err != nil {
        return nil, err 
    }
    c, err := b.baz()
    if err != nil {
        return nil, err 
    }
    return c

JoshTriplett3• 10 years ago

Exactly. It isn't just that it's shorter; it fixes a right-left-right-left alternating reading order, turning it into a left-to-right reading order.

Scaevolus2• 10 years ago

I think it also lets you turn this:

    try!(baz(try!(bar(try!(foo())))

into

    baz(bar(foo()?)?)?

Which isn't as bad as the alternating order for chained evaluation, but cleans up a lot of the noise.

bluetech• 10 years ago

Has anyone suggested some sort of postfix macro syntax? I don't have one in mind, but perhaps there is some nice looking, viable one. That might have been a more general solution than a new operator.

zalmoxes2• 10 years ago

As a Go developer, I'm curious how is the error handled when foo() or bar() fail? Could you show an example where `bar()` returns a re-triable error or a fatal error etc? something where I have to make a decision other than returning it up the call stack?.

Dobbs• 10 years ago

`try!(foo)` is roughly equivalent to this (invalid) code:

    foo().unwrap_or_else({ |e| return Err(e) })

Or in Go terms:

    a := try!(foo)

is equivalent to:

    a, err := foo()
    if err != nil {
        return nil, err
    }

Basically it will take the result of foo, and if foo returns an error it will return the error itself.

https://doc.rust-lang.org/beta/std/result/ has lots of examples of alternative ways you can deal with the error case, or the Ok() case of a result.

steveklabnik25• 10 years ago

When they fail, it's like "return err"; that is, they just return the error value.

You can only make it return up the call stack, that's it. It's for recoverable errors, not fatal ones. And the calling function would check for the error case and re-try if that's the behavior it wants.

Perceptes2• 10 years ago

The ? operator is a blanket "return from the current function if error, otherwise produce successful value." If you wanted to have conditional logic to handle the error within the current function, you'd use a match:

    let foo_ok = foo()?;

    let bar_ok = match foo_ok.bar() {
        Ok(bar_ok) => {} // conditional logic here
        Err(bar_err) => return Err(bar_err),
    };

    bar_ok.baz()

fizzbatter• 10 years ago

If you need more complex logic, you simply wouldn't use `try!()`. Try! is intended for those `if error then return` checks, just like with Go's `if err != nil { return err }`.

If the error needs to be checked for a specific type (like a timeout) and then retried X times, you don't use the simple `if err != nil {...}`, you hand write something:

    let barRes = try!(foo()).bar();
    match barRes {
      Err(MyError::Timeout(_)) => // .. some retry code
    }

Note that the above code is woefully incomplete (i'm not checking all possible match values, for example), but it should give you the gist of the idea.

edit: Man, the guy (or wo-guy) has a problem and we all pounce :)

masklinn11• 10 years ago

As a Go developer, I'm curious how is the error handled when foo() or bar() fail?

By converting their error to whatever the enclosing function returns, and returning.

Could you show an example where `bar()` returns a re-triable error or a fatal error etc?

You'd use either one of the various combinators[0] or a full explicit `match` (which is what try!, ? and the combinators end up desugaring to). So let's say you wanted special handling for bar()'s result, you'd specially handle that one:

    let a = foo()?;
    let b = match a.bar() {
        Ok(value) => {
            // the call succeeded
        }
        Err(error) => {
            // the call failed
        }
    }
    etc…

If you want bar() to be a fatal error, you can unwrap(), that desugars to:

    match v {
        Ok(v) => v,
        Err(err) => panic!("called `Result::unwrap()` on an `Err` value: {:?}", err)
    }

that is it panics on failure and unwraps the value on success (there's also an `unwrap_err` which does the opposite)

[0] https://doc.rust-lang.org/std/result/enum.Result.html#method...

bresc• 10 years ago

i actually don't think the Go version is bad. I can very clearly see what is happening and I can also do something with the error

vvanders2• 10 years ago

Nothing keeping you from using the same approach(or even some of the really nice mapping functions), it just lets you get rid of the boilerplate that you see there when you want to.

cpuguy833• 10 years ago

The only thing bad about Go's version (other than the usual repetitive code complaints) is it's easy to ignore (ie forget) to handle an error.

And really much of the error handling in Go is by convention (ie, `if err != nil { return nil, err }`) rather than actual language semantics.

Honestly it would be nice to be able to always return the error (without special macros or symbols) if there is one unless I've explicitly setup a handler block.

jhomedall• 10 years ago

You only have to learn what '?' does once. You have to write (and more importantly, read) the Go boilerplate every time.

PopsiclePete• 10 years ago

Same here. I value the readability more over the "oh no it's 20 extra key-strokes" drawback.

namelezz3• 10 years ago

I find the Go version to be easier to debug though.

junke5• 10 years ago

I hope so, because it is more subject to accidental copy-paste bugs.

pcwalton2• 10 years ago

Why? Can you explicitly name a type of mistake that might happen and explain how Go solves it in a way that Rust does not?

nercury3• 10 years ago

But consider that the Rust does not have null, so every case where you need to step over the code and see if it does the right thing when value is null does not need debugging!

masklinn11• 10 years ago

Nothing prevents you from writing

    let a = foo()?;
    let b = a.bar()?;
    let c = b.baz()?;

if that's what you want, not sure how the Go version would be easier to debug beyond that, and you can easily perform that transformation when you actually need to debug that code if the "pointfree" version hinders that.

stouset8• 10 years ago

Really? Really?

    foo()?.bar()?.baz()?

This is somehow less clear, and somehow "more debuggable" than

    a, err := foo()
    if err != nil {
        nil, err 
    }
    b, err := a.bar()
    if err != nil {
        nil, err 
    }
    c, err := b.baz()
    if err != nil {
        nil, err 
    }
    return c, nil

One of these obviously has no bugs. There is literally nothing to debug. The other has no obvious bugs.

Oh, except look again, I accidentally forgot to return from those error-handling-statements and now I have what should have been a completely avoidable bug.

Ask me how many times I've been bitten by this.

moomin• 10 years ago

That's because they're both >>= in Haskell. So is SelectMany in C#.

Or to put it another way, it's taking an operation that does this:

a -> t of b

And turns it into one that does this:

t of a -> t of b

There's a formal name for "t"s that support this operation. I'll let you guess what it is. :)

tatterdemalion5• 10 years ago

This is inaccurate. While Result is a monad, `?` in Rust is not the monadic bind. That's the `and_then` method.

lomnakkus7• 10 years ago

While it may be convenient, it's truly worrying such (EDIT: was "many") syntactic special cases are going into Rust at this point.

(It may be the case that these things absolutely cannot be handled in a systematic way in a no-GC/no-runtime language, but I'd really like to see some evidence that this is the case.)

steveklabnik25• 10 years ago

Which ones specifically worry you? I can't think of many, but I am also incredibly biased.

nercury3• 10 years ago

Not sure what you are talking about - it is the first bigger syntax addition since 1.0, and I actually want more.

Manishearth10• 10 years ago

how many

I can only think of one redundant feature, and that is the ? operator. This is because `try!` gets used very often in in a lot of code.

I can only think of one syntactic feature (redundant or otherwise) that doesn't get used often and that is HRTB(`for<'a>`), which needs to be there to be able to specify some types correctly (but is very rare).

bascule2• 10 years ago

This is a standard operator found in many programming languages, including ones with GC:

https://en.wikipedia.org/wiki/Safe_navigation_operator

To the contrary of what you're suggesting, I think Rust has done a great job eliminating a lot of the previous special-cased syntax and rebuilding things upon a simplified set of core primitives.

QuantumLogic2• 10 years ago

I don't get why they'll let the language be abstracted in that way, but are against having ternary operators. It's the one thing that's somewhat bugged me about Rust. Aside from this one minor thing, I"ve been really loving the language itself.

    let greater = a < b ? b : a;

Is a lot better than having to write this all the time:

    let greater = if a < b { return a; } else { return b; };

steveklabnik25• 10 years ago

This doesn't duplicate anything in the language; it moves a stdlib macro to be included in the core language.

Since if is an expression, ternay operators would be wholly redundant.

masklinn11• 10 years ago

But…. these are two completely different statements, the equivalent Rust is

    if a < b { b } else { a }

why are you adding sprurious returns? And if you need to get the minimum of two values so much that actually impacts you, write a `min!` macro?

sixbrx• 10 years ago

Ditch the returns and semicolons in the latter, then if is your ternary op, just more readable in cases where a and b are expressions more complex than in this example.

Gankro6• 10 years ago

I tip my hat to you for remaining committed to one of the oldest Rust trolls there is.

Animats6• 10 years ago

Versus the Python equivalent:

    try:
        foo().bar().baz()
    except Exception as message: 
        return message

paulddraper2• 10 years ago

It's true.

Rust doesn't have exceptions, for many reasons. One is non-locality of exceptions. Even gotos but bounded by a function. Exceptions, however...those can take you anywhere.

But the other side, as you point out, is that exception many common patterns are much made more succient.

saghm5• 10 years ago

I kind of like how I can't forget to handle some error because the compiler will tell me

0xAA55• 10 years ago

Versus the Ada equivalent:

    Foo.Bar.Baz;
  exception when Program_Error => Put ("WHoops");
            when Constraint_Error => Put ("Dang");
            when Gaim_OVer_Main => Put ("??? D: ");
            when others => Put ("IDC...");

alexnewman• 10 years ago

that doesn't do what you think it does

imtringued2• 10 years ago

That swallows all exceptions. You should instead use a more specific type.

prirun• 10 years ago

I think the Python equivalent is just:

foo().bar().baz()

ie, let someone higher up the stack handle the error.

iand5• 10 years ago

How do you decorate the errors? In Go I might write

    a, err := foo()
    if err != nil {
        return nil, fmt.Errorf("failed to foo: %v", err) 
    }

beefsack• 10 years ago

If you want something like this, you'd usually use your own error type to wrap the errors returned from the functions you call. You can implicitly do the conversions and keep the code the same if you implement `From` or `Into` for the wrapped error type.

ameliaquining• 10 years ago

You often won't need to change the error object from what foo() returns; Rust errors are generally structs or enums, rather than non-machine-readable strings. But if you do need to change it, it looks like this:

  foo().map_err(MyError::new)?

dasfasf• 10 years ago

I use error_chain

    let a = foo().chain_err(|| "failed to foo")?;

masklinn11• 10 years ago

`?` will convert the original error to the one the caller returns so you can implement the decoration in the conversion if that's suitable, otherwise `Result#map_err` lets you convert an error "at the callsite" (and is a noop if there was no error). Alternatively, you can use error_chain: https://brson.github.io/error-chain/error_chain/index.html.

hnakamur• 10 years ago

In Go, I use https://github.com/pkg/errors these days and wrap errors with stack trace.

  package main
  
  import (
          "fmt"
          "io"
          "os"
  
          "github.com/pkg/errors"
  )
  
  func main() {
          v, err := run()
          if err != nil {
                  fmt.Printf("err=%+v\n", err)
                  os.Exit(1)
          }
          fmt.Printf("v=%d\n", v)
  }
  
  func run() (*int, error) {
          a, err := foo()
          if err != nil {
                  return nil, errors.WithStack(err)
          }
          b, err := a.bar()
          if err != nil {
                  return nil, errors.WithStack(err)
          }
          c, err := b.baz()
          if err != nil {
                  return nil, errors.WithStack(err)
          }
          return c, nil
  }
  
  func foo() (*a, error) {
          return new(a), nil
  }
  
  type a struct{}
  
  func (a *a) bar() (*b, error) {
          return new(b), nil
  }
  
  type b struct{}
  
  func (b *b) baz() (*int, error) {
          return nil, io.EOF // some arbitrary error for demo
  }

This prints a useful stack trace like below and you can know where the error occurred.

  $ go run main.go
  err=EOF
  main.run
          /home/hnakamur/go/src/bitbucket.org/hnakamur/stacktrace-demo/main.go:31
  main.main
          /home/hnakamur/go/src/bitbucket.org/hnakamur/stacktrace-demo/main.go:12
  runtime.main
          /usr/local/go/src/runtime/proc.go:183
  runtime.goexit
          /usr/local/go/src/runtime/asm_amd64.s:2086
  exit status 1

jstimpfle3• 10 years ago

This is superficially nice, but let's not forget that we would hardly do this in practice. It's much more likely that we would write your Go version with some error handling or logging messages added in.

Practical concerns aside, in Haskell you get these things from the Maybe monad without extra syntax or macros:

  foo >>= bar >>= baz

webkike• 10 years ago

I'm pretty sure that ">>=" is "extra syntax". The only difference is in Haskell any function with two arguments can be interpreted as infix.

saghm5• 10 years ago

I think this would actually be more comparable to the Either monad. Also, "without extra syntax or macros" is kind of a trivial distinction, as `>>=` is just a function, not some sort of magic.

That being said, I really wish there were some sort of equivalent of `try` or `?` for options in Rust. I don't feel like I want monads in Rust in general, but when dealing with options, I definitely miss the Maybe monad.

jzelinskie• 10 years ago

I recently started checking out Rust and was quickly disappointed that it's near impossible to chain anything unless their signatures match perfectly. Subsequently, I found the `mdo` crate[0] to be rather useful, although I'm not sure how idiomatic it is. It's essentially a macro that implements Haskell's do-notation. Here's a snippet from the README:

     let l = mdo! {
             z =<< 1i32..11;
             x =<< 1..z;
             y =<< x..z;
             when x * x + y * y == z * z;
             ret ret((x, y, z))
         }.collect::<Vec<_>>();

[0]: https://crates.io/crates/mdo

sudeepj• 10 years ago

I think the new operator works only with Result. Had it been for Option also, it would have been awesome.

steveklabnik25• 10 years ago

It can be extended for Option in the future, we're just not sure that we're doing it yet.

(I personally am opposed, but I suspect I'm in the minority.)

imtringued2• 10 years ago

Write a function to turn Option into a Result.

amatheus• 10 years ago

Rust looks great, I'm not using it but learning and it look fantastic. I have one question, I guess off-topic: Rust uses LLVM, like Swift, Julia etc. Could these LLVM languages interoperate better because of this common foundation? Maybe link using LLVM IR instead of C ABI FFI, or something like that?

muizelaar• 10 years ago

Not obviously. For example, all of those languages mangle names differently.

TD-Linux• 10 years ago

The LLVM IR doesn't define an ABI - in particular, most of the ABI is already "burned in" at the point where LLVM IR exists.

Retra4• 10 years ago

LLVM has so many little ways to configure its output, and unless two LLVM users configure the outputs to be compatible, they are unlikely to be. LLVM is more of a toolset with some language than a shared infrastructure.

the_duke• 10 years ago

It's astonishing that, in just 6 weeks 155 people contributed. (1.12 was September 29th)

Rust sure seems to draw a lot of enthusiasm.

OJFord4• 10 years ago

They didn't necessarily actually contribute in that time though, presumably the list is of people who's contributions were merged into the release branch (or master during that timeframe, or... according to whatever workflow they're using).

Not to detract from your point though. It's an awesome language, I'm just learning it but enthusiastically so for sure!

Manishearth10• 10 years ago

I think it's the contributions merged in master that are in the 1.13 release but not 1.12.

However, the timeframe for that is the same -- it is a different period of 6 weeks, but still a 6 week period.

shmerl4• 10 years ago

How far along is the effort for efficient code reuse (such as filling the gaps of lack of inheritance)?

I.e. this:

* https://github.com/rust-lang/rfcs/issues/349

* https://github.com/rust-lang/rust/issues/31844

Is it something coming soon, or it's pretty far still?

steveklabnik25• 10 years ago

Specialization would only be one piece of the puzzle, and as you can see, it's not in stable yet.

All of the bits are still too far out to give a good estimate of.

shmerl4• 10 years ago

Thanks. Do you expect that to introduce some non backward compatible changes to language (and for example require a new major version)?

sametmax2• 10 years ago

Isn't that only necessary because rust doesn't have exceptions ?

steveklabnik25• 10 years ago

In some sense, yes. But in another sense, not everyone agrees that exceptions are a good idea, and so would prefer this even if we did.

Gankro6• 10 years ago

It's all the same stuff, man. Rust just:

* makes you be explicit about call sites which throw

* makes it easy to reify fallible computation (so it can be stored in e.g. a Future)

For instance:

    fn foo() -> Result<Value, IoError> {
      let x = a()?;
      let _ = b();
      if someCondition {
        return Err(IoError::Whatever)
      }
      return c(x).unwrap();
    }

is just

    Value foo() throws IOException {
      x = a();
      try {
        b();
      } catch(Exception e) { /* TODO: ERROR HANDLING? */ }
      if (someCondition) {
        throw new IOException();
      }
      try {
        return c(x);
      } catch(Exception e) { abort(); }
    }

This is made especially clear by Swift's model which is pretty much exactly the same as Rust's, but makes it look like exceptions:

    // RIP typed errors
    func foo() -> Value throws {
      let x = try a() // "rethrow"
      try? b()
      if someCondition {
        throw "Oh No IO!"
      }
      return try! c(x)
    }

computerphage• 10 years ago

I consider "not having exceptions" to be a feature that the ? operator helps to enable. Go also doesn't have exceptions, but they don't have the ? operator, which I find to be a little repetitive while coding. My fingers are outrageously good at:

if err != nil { return err }

Comparing Rust to a language with exceptions, like Java, the only difference is that they places that the code can return is explicit rather than implicit, because of that one extra character. I find this extremely pragmatic since most of the time errors just need to be propagated up to a place where they can be handled, but you still need to know when that may happen.

stouset8• 10 years ago

But technically you're doing this wrong, since you should be gift-wrapping your errors in Go. So either you have to be a human exception handler, or god help you should you need to figure out where an error actually occurred.

Manishearth10• 10 years ago

? isn't necessary, it's just nice to have.

Rust doesn't want to have exceptions; it prefers return value based error handling ("monadic error handling", specifically). A lot of people seem to be under the impression that Rust's error handling model is a way of emulating exceptions -- it's not; it's a different model, and we don't want to emulate exceptions. The fact that error propagation is a common task doesn't mean that Rust's way of providing it is done to emulate exceptions.

------

In a sense, every part of Rust's error handling model is "necessary because Rust doesn't have exceptions". Similarly, every part of Java's error handling model is "necessary because Java makes it hard to do monadic error handling". Saying "X is only necessary because you don't have Y" when X is an alternative to Y isn't a very useful statement.

sametmax2• 10 years ago

You are just answering to the style of my question, while you perfectly understood the meaning and avoided to provide the answer.

Basically this feature is here to provide an easy propagation of errors, something an exception system does for you for free.

"?" exist because the current error handling make it inconvenient to propagate errors, and is a workaround to make it less of a pain.

It's alright. There is no shame in it. Just say so, don't try to talk your way out of it.

bascule2• 10 years ago

No, this is a standard operator found in many programming languages, including ones with exceptions:

https://en.wikipedia.org/wiki/Safe_navigation_operator

Animats6• 10 years ago

Well, it's concise. The main problem is that the error action is "return" - you have to bail out of the entire function.

What happens if you use "?" within a lambda? Does it bail out of just the lambda, or the entire function? What about nested functions? (Can you have a named nested function which can access its outer scope? This StackOverflow post [1] says no, but may be wrong or obsolete.)

If this works with nested block structure, it's more useful. Having a "match" for Err/Some around a lambda with with lots of "?" clauses would be useful. That provides a way to get the error from some complicated chain without leaving the function.

[1] http://stackoverflow.com/questions/26685666/a-local-function...

wyager2• 10 years ago

The answer seems obvious; it's the same behavior "return" has, i.e. it returns from the function it's currently in, not something a few levels up.

steveklabnik25• 10 years ago

It might seem obvious, but Ruby, for example:

  def lambda_test
    lam = lambda { return }
    lam.call
    puts "Hello world"
  end

This will print "hello world". But this:

  def proc_test
    proc = Proc.new { return }
    proc.call
    puts "Hello world"
  end

Will print nothing, as the 'return' returns from proc_test. Examples taken from here: http://awaxman11.github.io/blog/2013/08/05/what-is-the-diffe...

steveklabnik25• 10 years ago

  >  Does it bail out of just the lambda

Yes.

  >  What about nested functions?

It returns from the nested function, not the outer function.

  > a named nested function which can access its outer scope?

No, functions don't close over any scopes.

Animats6• 10 years ago

That's good. Now there's a clean way to handle errors in a block-structured fashion.

kibwen• 10 years ago

The semantics are very straightforward: `?` will return as per the `return` keyword. So if you use it in a lambda, it will return from just the lambda, like returns in lambdas always do (Rust hasn't hewed to Tennent's Correspondence Principle for a long time now :P ).

richardwhiuk3• 10 years ago

It bails out of the lamda - https://is.gd/0TT8pr

Lamdas can capture their scope, and you can give them a name, so that might be useful? You can't use named functions (as per fn foo).

tatterdemalion5• 10 years ago

What you describe as "a match around a lambda" is the `catch` expression, which will catch `?`s thrown within it and allow you to match over them. This syntax has gone through RFC but its not implemented yet.

Of course for now you can create this control flow with `match (|| { block }) { }` as you describe.

randyrand• 10 years ago

Can someone explain to me why rust decided not to support pattern matching with different types?

Suchas:

let x = Bus();

match x{

   Car => ...

   Bus => ...

   Person => ...

}

You would need to have runtime type information of course, this could be a compiler flag.

elihu• 10 years ago

Because rust is statically typed, and "x" has to have a concrete type known at compile time?

Maybe there's a use case for matching trait objects against types to get back the original type. But, I think you could do the same thing by adding a trait method that returns Option<T> for some desired type T. If the object wasn't that type, it could just return None.

tatterdemalion5• 10 years ago

And this is actually implemented by the Any trait.

https://doc.rust-lang.org/std/any/trait.Any.html

Manishearth10• 10 years ago

https://doc.rust-lang.org/std/any/trait.Any.html#method.down... ? :)

stouset8• 10 years ago

Why can't you already do this with an enum?

Rust isn't go. You don't have to break out of the type system because it doesn't have generics.

Manishearth10• 10 years ago

Rust has static types with generics and algebraic data types. 99% of the use cases for that get covered. It has trait objects for when you need runtime type information, but they're used very rarely and you can make that pattern work with a chain of `downcast_ref` if lets or obviate its need by implementing methods.

tmaly• 10 years ago

I am thinking about learning Rust sometime in the near future.

I am curious how long it took you to learn and become proficient?

iopq• 10 years ago

I've been coding Rust for three years in my free time and I'm still working on it.

saheel1511• 10 years ago

I'm in no way proficient but I am a TA for an entry level OOP course at an UC. It took me 2 weeks to read through the major topics in Rust. And another month to get a good hold by gradually writing bunch of code.

echelon• 10 years ago

I am in no way proficient, but I've been using it casually for about a year. I'm just now starting to feel really comfortable with it.

glennsl• 10 years ago

Good to see bors[0] getting some well deserved credit. That guy's a beast!

[0] https://github.com/bors

steveklabnik25• 10 years ago

Bots are people too!

Animats6• 10 years ago

OK, here's some error handling I wrote about a year ago, for an RSS feed reader. This code calls lots of packages with their own error types. If anything fails, an error bubbles up. Those had to be packed up into a single type for Rust's error handling. What's changed that would make this more concise?

    pub type FeedResult<T> = Result<T, FeedError>;  // return type, result or error

    // A set of errors that can occur handling RSS or Atom feeds.
    pub enum FeedError {
        FeedIoError(io::Error),                         // error at the I/O level
        FeedHTTPError(hyper::Error),                    // error at the HTTP level
        FeedXMLParseError(xml::BuilderError),           // error at the XML level
        FeedDateParseError(chrono::format::ParseError), // error at the date parsing level
        FeedUnknownFeedTypeError,                       // wrong feed type
        FeedFieldError(String),                         // required RSS field missing
        FeedWasHTMLError(String)                        // expected XML, got HTML
    }
    //
    //  Encapsulate errors from each of the lower level error types
    //
    impl convert::From<hyper::Error> for FeedError {
        fn from(err: hyper::Error) -> FeedError {
            FeedError::FeedHTTPError(err)
        }
    }
    impl convert::From<io::Error> for FeedError {
        fn from(err: io::Error) -> FeedError {
            FeedError::FeedIoError(err)
        }
    }

(More of those are required, one for each enum value...) (Then we need this.)

    //   Convert FeedError to text string.
    impl fmt::Display for FeedError {
        fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
            match self {
                &FeedError::FeedIoError(ref xerr) => xerr.fmt(f),   // I/O error
                &FeedError::FeedHTTPError(ref xerr) => xerr.fmt(f), // HTTP error
                &FeedError::FeedXMLParseError(ref xerr) => xerr.fmt(f), // XML parse error
                &FeedError::FeedDateParseError(ref xerr) => xerr.fmt(f), // Date parse error
                &FeedError::FeedUnknownFeedTypeError => write!(f, "Unknown feed type."),
                &FeedError::FeedFieldError(ref s) => write!(f, "Required field \"{}\" missing from RSS/Atom feed.", s),
                &FeedError::FeedWasHTMLError(ref s) => write!(f, "Expected an RSS/ATOM feed but received a web page \"{}\".", s)
                //_(ref xerr) => xerr.fmt(f) // would be convenient, but not allowed in Rust.
            }
        }

This sort of thing is why I like Python's exception hierarchy. If you catch the higher level errors, you get all the lower level ones, too, without losing the info about what went wrong.

Arnavion3• 10 years ago

https://crates.io/crates/error-chain or https://crates.io/crates/quick-error (which error-chain uses and adds to) provide macros to help with defining error types.

Edit: Specifically with error-chain, you get:

- Concise declaration of the enum for each wrapped error type (your first code block).

- Automatic impl of From for each wrapped error type (your first code block).

- A custom Result type (your first code block).

- Concise way to define description() functions for each enum variant, which get used for the Display impl (your second block). For "foreign_links" it would forward to the wrapped error's fmt automatically, so you only need to do this for the others.

- Bonuses like backtraces conditional on RUST_BACKTRACE=1

Animats6• 10 years ago

How well does that play with packages that don't use it? There seem to be several such packages.

chubot• 10 years ago

I think Python's exceptions work pretty well, but how do you make use of the hierarchy? It's not clear to me from this example.

I find myself using Python exceptions in two pretty disjoint cases:

1) try/catch around a single line, where the exception is as specific as possible (e.g. KeyError, etc.). To do something specific in the error case, perhaps decrement a retry count. (Although this is one of those places where "exceptions should be exceptional" comes to mind; I don't like "except" for normal control flow...)

2) try/catch around main(), where the exception is as general as possible. To log the exceptions, or perhaps print a usage message.

There doesn't seem to be much usage between those two extremes.

I recently read "The Design and Evolution of C++" by Stroustrop, and it was not obvious to them to use the class hierarchy for exceptions. I'm not sure exactly where the idea originated from. (He also talks about resume after exceptions, which sounds insane today, but was pretty heavily debated at the time.)

Go has no class hierarchy, and I believe the error handling is with an Error interface. Although I guess is does have some kind of subtyping by creating a more specific interface than Error by adding methods.

Animats6• 10 years ago

The class hierarchy for exceptions is a library standardization concept in Python. Exceptions were rather haphazard in early Python, but got organized around Python 2.6-2.7. All exceptions descend from "Exception". Usually, though, you don't want to catch that. If you do, it's usually to log the error or report it someplace before aborting the program.

"EnvironmentError" includes most of the things that can go wrong external to the program; it subsumes OSError and IOerror and all the networking/HTTP errors. Modules which do I/O or network operations should catch EnvironmentError and do something about it. Your GUI program or web service shouldn't abort for an EnvironmentError. Code can and should catch more specific errors at lower levels, but a backup exception handler for EnvironmentError is useful for when something that "never" fails does fail.

I have a moderately large Python system which reads and processes arbitrary web pages, trying to rate web sites. Such a program sees all the things that can go wrong with networking, HTTP, and HTML. Functions in standard packages functions sometimes raise unexpected exceptions. None of those events are abort conditions; they have to be dealt with as ordinary problems. Some errors require "try again", some require "try again later", and some require "never try again". Errors log to the database, not a log file, and some are reported on the rating page for a site. The point of all this is to have a system which requires very little human attention. It's been several years since I had to deal with a system failure manually.

tatterdemalion5• 10 years ago

In addition to libraries like quick error and error chain, you can just use coalesce your errors into `Box<Error>` instead of defining an enum like this.

kccqzy• 10 years ago

Excuse me if this is a stupid question, but when I downloaded the official Mac installer, it's not signed by anyone. I thought in this age we've all recognized that downloaded software should be signed, whether it's using GPG or Apple's signature mechanism? Is there a reason the Rust team decides not to sign their binaries?

steveklabnik25• 10 years ago

https://github.com/rust-lang/rust/issues/27694

GPG signatures do exist for the tarballs, though, see

https://static.rust-lang.org/dist/rustc-1.13.0-src.tar.gz.as... for the source, for example, or https://static.rust-lang.org/dist/rustc-1.13.0-x86_64-apple-... for rustc.

http://rustup.rs/ will automatically use all of this if you have it installed and our key imported.

stirner3• 10 years ago

It seems like a fairly common case for a Rust function to encounter multiple types of error when it runs. My only solution to this is to return a custom error type, but this means manually matching rather than using something like try! or ?.

Can someone with more experience than I tell me if there is a simpler approach?

stjepang• 10 years ago

Yes, there is a simpler approach.

If your function returns Result<T, Box<Error>>, then you can use try! or ? operator to return any kind of error. It will be automatically boxed and converted into the generic Box<Error>.

This works for two reasons:

1) try! and ? don't simply return Err(err) on error case as one might think. They actually return Err(From::from(err)).

2) The standard library has: impl<'a, E: Error + 'a> From<E> for Box<Error + 'a> { ... }

Check out this article, starting from "The From trait": http://blog.burntsushi.net/rust-error-handling/

stirner3• 10 years ago

Awesome, thanks. Does returning boxed errors have a performance impact?

stirner3• 10 years ago

Another solution I hadn't considered is to simply impl std::convert::From<SomeError> for your custom error type for each SomeError that might be encountered.

cjg• 10 years ago

Worth noting:

"1.13 contains a serious bug in code generation for ARM targets using hardware floats (which is most ARM targets). ARM targets in Rust are presently in our 2nd support tier, so this bug was not determined to block the release. Because 1.13 contains a security update, users that must target ARM are encouraged to use the 1.14 betas, which will soon get a fix for ARM."

hossbeast• 10 years ago

Is it "written in rust" ?

steveklabnik25• 10 years ago

Yes.

Announcing Rust 1.13

Related Stories