How to propagate error from `Timeout::new` inside an `and_then`

[p-jackson]

I'm learning about Tokio and was working with some tutorial code like this:

extern crate futures;
extern crate tokio_core;

use std::time::Duration;
use tokio_core::reactor::{Core, Timeout};
use futures::{Future, future};

fn main() {
    let mut core = Core::new().unwrap();

    let handle = core.handle();

    let future = future::ok(())
        .and_then(|_| {
            println!("Wait ...");
            let d = Duration::from_secs(3);

            // How do I propagate this error?
            Timeout::new(d, &handle).unwrap()
        })
        .map(|_| println!("Done"));

    core.run(future).unwrap();
}

How would you avoid unwrapping the result from Timeout::new? Why doesn't Timeout::new just return an immediately failed future if there's a failure during construction? That way you could just return it from the closure directly.

|_| {
    println!("Wait ...");
    let d = Duration::from_secs(3);
    Timeout::new(d, &handle)
}

[p-jackson]

I propagated the error using a boxed trait object to force things to the same type:

|_| -> Box<Future<Item = (), Error = io::Error>> {
    println!("Wait ...");
    let d = Duration::from_secs(3);

    match Timeout::new(d, &handle) {
        Ok(f) => Box::new(f),
        Err(e) => Box::new(future::err(e)),
    }
}

Also interested to hear if there's just a better way to do what I'm trying to do 😃

[alexcrichton]

One method of taking io::Result<impl Future> to a future itself is perhaps .into_future().flatten() I believe. Would that suffice in this case?

[p-jackson]

Yes, that's perfect 👌
Will use that in the future

Is there ever a case where you wouldn't want an already flattened future though? That API would seem more ergonomic (to me at least), and the current API exposes an implementation detail (e.g. what if in the future the generation of the timeout token was deferred?)

Happy to close the issue too 😃

[alexcrichton]

It's true yeah it's definitely not the most ergonomic of interfaces. In reality the only "error" case here is that the event loop has entirely disappeared and you're trying to add a timeout to it.

I imagine that we could reasonably consider panicking in such a case instead of returning an error. Either that or just encapsulating that error in the future itself (like you've said).

I'll tag this for 0.2 as right now it'd be a breaking change to alter the signature, but we should certainly consider it when making the next major release!