You should try using `map_err` and the `?` operator, with your own error enum defined using the `failure_derive` crate, for example:

    foo().map_err(|e| MyError::FooError(e))?
      .bar().map_err(|e| MyError::BarError(e))?;

A tip - you usually don't need lambdas in such cases; this should work:

    foo().map_err(MyError::FooError)?
      .bar().map_err(MyError::BarError)?;

Oh, nice! I did not realize tuple constructors implemented `FnOnce`! Thanks for the tip!

d'oh - you beat me to it ;)

For error handling, check out failure if you haven't already: https://github.com/rust-lang-nursery/failure

Does it help with Error enum coming for third party crates? I can see how it will help with my own code though

> Rust comes with a default unit test framework but it pretty bare bones. I havent seen examples of test fixture, setup/teardown support and loading test configs etc.

This is one of the things that I really love about Rust - it has a testing framework that is so simple that it subtly pushes you to write better tests and better code.

What I mean by that is - it really wants you to write simple tests with no mocking and no convoluted state using simple asserts, and it really wants you to write code which is trivially testable. In other languages this might be problematic, but in Rust this synergises really well with other language features such as #[derive(...)], sum types and pattern matching. If you write good, idiomatic Rust code then all of those extra features of other testing frameworks are usually totally unnecessary.

I can see your point for unit testing but I am struggling to see how it will work for Integration testing. For example I would like to initialize a connection pool (or other heavy object) only once for the entire test, I .. havent figured out how to handle that except for creating a new one in each test. Any pointer on how you are handling those? Thanks

I know a little about two of the big open source Rust projects, Servo and the Rust compiler.

For integration tests, both the Rust compiler as well as the Servo web engine have written their own test runners with an accompanying set of tools. This allows the test format to be as flexible as the target domain of the program. In fact, servo can just simply use the cross-browser wpt [1] test suite.

As for avoiding to initialize heavy objects, I only know about the Rust compiler's test runner initializing the entire compiler every time from zero for every single test file. The result is a quite long testing-time. Suggestions by me to use a shared driver were rejected by them because one test might affect the other one.

But in theory you could write your own custom test runner that has as much shared state as possible. You might also want to check out cucumber-rust [2] which I think allows for some way of sharing. You could also just group smaller tests into a small set of bigger tests where each group of tests shares some resource.

[1]: https://github.com/web-platform-tests/wpt [2]: https://github.com/bbqsrc/cucumber-rust

If it's something that doesn't take too much wall time I just simply initialize those from scratch for every test. If I have multiple tests which need some complex setup I just put that down in a separate function and call that in every test. If it's something reaaally expensive to initialize I just use lazy_static:

https://crates.io/crates/lazy_static

Have you looked at stainless?

> every single Rust crate I have used so far its creating its own `Error` enum which makes it really hard to compose `Result`.

Is there a reason why `map_err()` doesn't achieve what you need - i.e. to get everything into your error type no matter where it came from?

For example: OtherLibResult.map_err(|e| MyError::from(e))

Unless I'm mistaken - you ultimately are doing something like this in one form or another, because if you never match on the different Error variants that happened somewhere along the pipeline- then those details are being swallowed.

Implementing a From trait at least forces you to make that choice (all in one place too)- and then you can keep composing the results as needed since it's all in your MyError type

Yes thats the pattern I ended up using with the help of `custom_error` crate which automates the implementation of `From` for your custom errors. I guess the disconnect for me was that in Java/Scala all custom exceptions extend `Throwable` so types always line up, in rust custom Errors are disjointed so you have to wrap everything yourself to align the types.

`Throwable` in Rust is `dyn std::error::Error`.

If you make your functions return `Box<dyn Error>` (or `failure::Error`), they will all convert out of the box. The `?` operator performs conversion itself. For chains `.map_err(From::from)` does it.

> - Rust comes with a default unit test framework but it pretty bare bones. I havent seen examples of test fixture, setup/teardown support and loading test configs etc.

There is an eRFC for better integration of custom test frameworks.

https://github.com/rust-lang/rfcs/pull/2318

For non-code assets, do you know about `include_bytes`?

I found rust-embed recently[0], which lets you embed an entire directory in release mode while deferring to the file system in debug mode.

[0]: https://github.com/pyros2097/rust-embed

Have you also evaluated Scala/Rust interop?

That would be an ideal combination for me: do performance critical stuff in Rust, use Scala everywhere else.