Recover from errors with move semantics

[MoreDelay]

I tried out exn in a project of mine to see how this error handling paradigm feels. I like how there is much less boiler plate created by meticulously tracking all error cases in an enum using thiserror. On the other hand a lot of type information is lost and now it becomes a runtime issue whether you get back the correct values from your error context. In my opinion, this hurts quite a lot, and it seems other people have similar experiences (like here).

In particular, I am interested in a way to recover from an error that does not reqire to clone out your value from the error tree. I like to design my programs around Affine Types, i.e. non-clonable objects which is in a way the default property of rust's structs. This property is quite handy in many places as many things are either handled once or get transformed into the next object. This makes the compiler enforce your domain model as you design it. At other times, an object may not be clonable at all, such as complex objects holding threads or mutexes, or objects holding a lot of data. When performing a task with these objects, they often get consumed by a method. But now we also need to handle errors of these methods, from which we may want to recover without just dropping the value.

To give you an idea how this style works, here is a simple example from my project on how I use affine types to act as a witness for some property.

#[derive(Debug, Clone)]
struct Directory(PathBuf);

impl Directory {
    fn new(path: PathBuf) -> Result<Self, PathBuf> {
        match path.is_dir() {
            true => Ok(Self(path)),
            false => Err(path),
        }
    }
}

This example may be very simple and here it would also not hurt to clone. However, at other times the struct may represent a task that should only be successfully completed once.

pub enum TaskDescription {
    DoA,
    DoB,
    DoC,
}

pub struct Task {
    desc: TaskDescription,
}

pub enum TaskError {
    Recoverable(Task),
    Impossible,
}

impl Task {
    pub fn new(desc: TaskDescription) -> Self {
        Self { desc }
    }

    pub fn run(self) -> Result<(), TaskError> {
        use TaskDescription::*;
        match self.desc {
            DoA => Err(TaskError::Recoverable(self)),
            DoB => Err(TaskError::Impossible),
            DoC => Ok(()),
        }
    }
}

As far as I can see, we are only able to get a shared reference inside the error tree. So to be able to move items out of the error tree right now, one needs to create an error with a RefCell<Option<T>> field, which is not really nice especially as this is code written by users. However, a mutable reference would not change much either, as we still have to keep the Option<T>, which will still only check on runtime for correct usage such as not moving out a value twice.

As I came to like the approach of exn for non-recoverable situations, I would like to have support for these situations as well. I did some experiments and will link a pull request here as reference (see #44). A way to recover from errors with move semantics, combined with an untyped error (#35) for error messages used all the way throughout the application or even library, seems to be a promising paradigm to use in my programs from now on.

[andylokandy]

Thanks for bringing this up! I've read your pr #44, where only one top recovery value is preserved. It make me think that if a Result<T, (R, Exn<E>)> is what you want: when encountered into an error, you'll get a owned recoverable value and an Exn maintaining the error context.

Although rust is an programing language designed on top of affine type, it's not mature enough on that to make it possible to program something useful without reference/clone. That's said, until now, you're not allowed to DerefOwn from a container, where Box is a special case as lang item. I mean, if we want to make something really useful in the real world in Rust, reference and clone is somehow unavoidable.

[MoreDelay]

You are right, I just got the idea to make a tuple in the error case shortly after posting this issue. It's kind of weird how this idea only pops into my mind after clicking submit, even though I spent so much time thinking about and preparing this issue.

This design option now greatly reduces the need for this feature. However, I would still say there is some merit in an extra field in the Exn struct. Or perhaps you can think of a solution for that too?

When we return Result<T, (R, Exn<E>), it becomes awkward to short-circuit the error case when we are not interested in recovering. In the first example I gave, we may expect to get a directory path, so when Directory::new returns an Err case, we now need to match on the result to extract the Exn object and return it explicitly.

impl Directory {
    fn new(path: PathBuf) -> Result<Self, (PathBuf, exn::Exn<ConversionError>)> {
        match path.is_dir() {
            true => Ok(Self(path)),
            false => {
                let msg = format!("Provided path is not a directory: {path:?}");
                let err = exn::Exn::new(ConversionError(msg));
                Err((path, err))
            }
        }
    }
}


fn run_on_dir(root: PathBuf) -> Result<(), exn::Exn<ConversionError>> {
    let err = || {
        let msg = format!("Failed to run on directory");
        ConversionError(msg)
    };

    // This no longer works:
    // let root = Directory::new(root).or_raise(err)?;
    //
    // Instead we have to match manually now:
    let _root = match Directory::new(root) {
        Ok(root) => root,
        Err((_, exn)) => return Err(exn.raise(err())),
    };
    todo!()
}

This can be solved by adding a new extension trait for Result<T, (R, Exn<E>> specifically to handle this case (this can not be added to the existing extension trait as there are conflicting impls). However, this is not satisfactory as it does not document itself by following opaque rules, such as that the order of the recovery value and the Exn struct must be strictly followed, never mind that this adds basically a copy of the existing trait.

Lastly, I want to mention that I too don't think a complex program can be made only out of affine types. But they can be a useful tool in parts of that program, such as the example I gave with running a task to completion. Or another example is the assignment of resources across threads, which should be returned to the main thread even when their task failed. As I lean heavily into trying to model my problem domain without Clone, I come across these situations more often. Perhaps it is a niche style to program, but in these cases they help me to avoid logic errors.

[feefladder]

I had basically the same issue and really like the tuple solution, but it still needs an Option in my case.

However, I had another idea as how move semantics may come into play. This assumes the following:

• getting an error with move semantics means you are recovering irreversibly
• as far as I could see, this is only possible on the top-level error, since all children are only accessible as &Box<dyn Error>, which can't be moved, since it's in a Vec.

But it would be possible on the top-level quite easily I think:

impl<E: Error + Send + Sync + 'static> Exn<E> {
    pub fn into_error(self) -> Box<dyn E> {
        self.frame.error
    }

then use like playground:

pub enum MyError {
  Fatal,
  Ignoreable(Vec<u64>),
}

fn do_ignore(err: Exn<MyError>) -> exn::Result<Vec<u64>> {
    if matches!(err.deref(), MyError::Ignoreable(_) {
        // recover nicely from this error
        Ok(*err.into_error().downcast().unwrap())
    } else {
        // the error and its tree are still alive here
        Err(err)
    }
}