Understanding how to use try!


#1

So, I’ve recently faced the try! macro for files manipulation (open, create, create_dir). It seems cleaner with try! of course, but I’m faced with one specific problem - they return explicitly. This means I can’t put them in main or any other method which has a different signature, so I end up either avoiding it (e.g. doing the long match) or have to wrap them in separate function. Now, my guess is that I just did not get the correct intention from the authors of what’s the correct idiom for it to be used. For instance, I’m also wondering and how do the examples on the docs for creating, opening files even compile (e.g. what flags you use to suppress) , since at the moment trying to make those examples you get:

mismatched types:
 expected `()`,
    found `core::result::Result<_, _>`
(expected (),
    found enum `core::result::Result`) [E0308]

#2

I’d recommend reading http://blog.burntsushi.net/rust-error-handling/.

Or, you can just do what I do:

  1. Decide on a unifying error type; String, Box<Error> or a custom one (you can make them fairly easily with the error-type crate).

  2. Define a top-level type Result<T> = ::std::result::Result<T, CommonError> alias.

  3. Make everything return a Result<T> the moment anything it calls returns a Result. Everything.

  4. Make main a thin wrapper around fn try_main() -> Result<()> { ... }.

  5. Never worry about this ever again.


#3

I mean jezzz… that article should be part of the docs. It’s like making everything so much clear and presents these all the ideas in a logical sense … truly I’m amazed how much that thought. If someone can include at some point this as an official tutorial or smth I think would be really great.


#4

We’ve been talking about pulling it into the docs, but we just haven’t
actually gotten it done yet.


#5

Steve, I’m not sure how relevant it would be to you, but since I’m on the topic I was thinking that this read http://scialex.github.io/reenix.pdf might be of interest to some of the core team for considerations. As the author have mentioned in the paper, some of the things are covered in some RFCs, but never the less I do not know if you have come across it or not, so just give it there if you might find it useful in any way (or maybe point it to the right ppl since I’m not sure where to post such kind of info)


#6

Oh yeah, I read and loved that paper when it came out.