Continue execution even if the Result is Err and return an error later

I have code of the following structure

fn run() -> Result<(), failure::Error> {

Actually, the save_the_details and send_an_email actions do not depend on each other - i.e. even if save_the_details fails I want to continue and send_an_email anyway. If only save_the_details failed, I want to the function to return an error, even if send_an_email succeeded. If both of them fail, I want to return an error indicating that both of them failed.

What’s the idiomatic way of handling this? Unfortunately, neither Vec<Result<T,E>> nor Result<T, Vec<E>> do not implement Fail so they cannot be used with failure. (and using ? would fail anyway due to type mismatch)

Is this an error that you'll be pattern-matching on in the caller or just informational? If it's important for the caller to know that both pieces failed, then you should define your own error type (that derives Fail) where you capture this fact.

I’d probably reach for something like this:

fn run() -> Result<(), failure::Error> {
    let r1 = save_the_details();
    let r2 = send_an_email();
    match (r1, r2) {
        (Err(e1), Err(e2)) => { ... do something with both errors ... }
        _ => { r1?; r2?; }

If you’re used to languages like Java, you can think of "? later" as finally. So

try { foo() } finally { bar() } // pseudo-Java

Translates into something like

let r = foo(); bar()?; r?

I'd create a new AggregateFailure type to represent a collection of errors that just contains a Vec<Error>.

Another approach is to create some sort of Diagnostic type which gets passed into your function as &mut Diagnostic. Then whenever there's an error the functions will call some add_error() method to add an error to the diagnostic struct. This is essentially what rustc does to aggregate the errors encountered during a pass and then present them all at the end (instead of stopping at the first error like normal ?).

This doesn’t seem to scale, what if there are n actions which can fail but we want to execute all of them and return an aggregate error.

… and implement Fail for AggregateFailure and then return it as a usual error, that’s what you mean?

Hm, now that I think about it, I recall frunk has a feature whose use case is, as far as I can tell, pretty much exactly this. You build a result-like type that holds an HList (basically a variadic tuple) for success, or a Vec of all errors.

The "aggregate error" is the hard part here, since giving that a type is awkward. It could be (Option<E1>, Option<E2>, ...), but that's not quite right since (None, None, ...) wouldn't actually be possible. Is there a big reason that all the errors are needed, and not just one of the errors?

Any reason the errors can’t be contained in a Vec<Box<Error>>? Do they need to be inspected by type somewhere? It’s still unclear what the error handling requirements are.

Sorry for the delayed reply, I’ve been so busy recently.

The problem is that if I use Vec<Box<Error>> I can’t use failure's context capabilities. Moreover, this code won’t work, since Vec<failure::Error> doesn’t implement Fail, even though failure::Error does :

extern crate failure;
use std::fs::File;
use std::io;

fn opensome() -> io::Result<()> {

fn always_fail() -> Result<(), ()> {

fn check_both() -> Result<(), Vec<failure::Error>> {
    let mut v = Vec::new();
    opensome()?; // this error is unrecoverable w.r.t this function
    let os = opensome(); // if this fails, we should continue, though and try `always_fail`
    if os.is_err() {
    let xd = always_fail();
    if xd.is_err() {

fn main() {
    println!("Hello, world!");

Here, the two first errors can be treated as unrecoverable - is my case it’s actually failure opening some configuration file or executing a child process.

The last two errors are not fatal - they are different means of logging, notifying. In my case, it’s a failure sending an e-mail to the user or writing logs.