Reconsider top-level move semantics

[andylokandy]

PR #48, feat: top-level move semantics, authored by @feefladder, introduced Exn::into_error(self) -> E.

That change was meant to address the move-based recovery use cases raised in #43 and, indirectly, the broader tension discussed in #40.

After looking at the use cases and the API shape more closely, I think we should reconsider whether top-level move semantics fit the intended model of exn.

The main concern is that into_error() only works for the current root error. That creates an awkward asymmetry with raise and or_raise, whose whole purpose is to add a new top-level error and push the previous exception tree into children. Once that happens, the previous error is no longer recoverable through into_error(). In practice, this creates the wrong incentive: code that wants move-based recovery may become reluctant to add context, even though preserving contextual structure is one of the crate's main strengths.

There are a few constraints here. raise really does change the semantic root; it is not just attaching metadata. Recovering a middle frame as a fresh Exn<T> is necessarily lossy with respect to discarded ancestors. Exn::new also stringifies ordinary Error::source() chains, so typed owned recovery can only ever work for explicitly stored typed frames. And more broadly, move semantics on errors seem like a niche use case compared to inspection, logging, reporting, and boundary mapping.

I see four possible directions. We can keep into_error() as-is, which is simple and convenient for the root case, but also leaves us with a root-only capability that may distort how users think about raise and or_raise. We can remove into_error(), expose Exn::into_frame(), and make Frame public enough for users to build their own owned traversal, but that leaks internals and creates a large semver burden around representation details. We can go the other way and add a real owned traversal story, such as into_frame, into_children, and Frame::downcast<E>(self) -> Result<Exn<E>, Self>, which would be much more coherent if we truly want move semantics, but is also a much larger feature commitment. Or we can decide that move semantics are simply not a first-class exn feature, and position exn errors more clearly as contextual views of failure rather than as transports for move-only recovery values.

My current leaning is the last option. If we do not want to invest in a full owned traversal design, I think keeping a top-level-only into_error() is worse than removing it. It is a narrow capability, but it nudges users in exactly the wrong direction by making root identity matter too much. If that reasoning holds, then PR #48 should likely be reverted. That is not because the implementation is wrong on its own terms, but because the capability it introduced may not fit the long-term model of the crate.

I would especially like feedback on two questions: whether move-based recovery is common enough in real exn usage to justify a larger owned traversal design, and whether it is better to remove into_error() now, while the change is not released yet.

cc @MoreDelay @macier-pro @feefladder @tisonkun

[feefladder]

hi, thanks for the write-up. I understand the reasoning. I currently have two lines of thought on this, mostly towards "keep into_error as top-level", but that does not mean I disagree if people decide to remove #48.

real-world usage: here is where I use it, does that count ;)? In case #48 is reverted, I do think then the into-error example should be updated, to give an alternative similar to Result<(),(Option<Partial>, Exn<E>)>, but slightly more ergonomic.

• top-level error handling.
  • Deref only works on the top-level Exn<E>. If functions that work only on top-level create the wrong incentive, then that applies to Deref as well. I think Deref and into_error work nicely together now in the example and my code.
  • I love the context of this crate, that's why I'm here. It's amazing how every struct/function/step returns a different error, forcing the user to add context. I was thinking that even top-level error handling incentivizes adding context, because the layer below has to convert into a Deref'able, retryable error. But then again, it also forces the error handling to be exactly one layer higher, which is not always ideal.
• walking a tree with move semantics.
  This is very destructive. As I understand currently, one would have to walk the tree twice: First to find out if there is any recoverable error, and then to find it with move semantics, destroying the error tree in the process.
  I think that's not really worth the effort for this use-case. For non-top-level errors, there is no deref/into combination. I think cloning at the point of tree traversal is fine.
  However, for returning a sub-tree, as requested in [Feature Request] Recover a sub Exn error from children frames #40, it would bring that a step closer?

that's my 2 cents. I would mainly like into_error to stay for cooperation with deref. I also wonder a bit for which use-case deref was implemented and if it is the same one.

[andylokandy]

Thanks @feefladder, this is helpful.

I think the symmetry point is important here.

Deref is top-level in the sense that it operates on Exn<E>, but borrowed access does not stop at the root because users can still walk frame() and downcast_ref() into erased intermediate frames. So the current borrowed story is not actually root-only.

into_error(), on the other hand, is root-only with no corresponding story for intermediate frames. To me, that suggests a more fundamental asymmetry: either we support move semantics with a coherent story for both top-level and intermediate frames, or we do not support move semantics as a first-class capability at all.

That leads to the bigger question, which is really about the role of exn. Should exn primarily be an error view, a report, a contextual backtrace, or should it grow toward a more general-purpose error framework that also carries owned recovery semantics? My current intuition is still closer to the former.

I also have a broader concern which may be independent of exn: if Result<T, E> is expected to return partial data in the Err branch, that may sometimes be better modeled as part of the normal control flow rather than as error handling. This is only my current view, and I do not want to overstate it, since there may well be real cases where this is hard to avoid. So far, though, I have not personally run into many examples that clearly require move-based recovery in error handling itself. Real-world examples here would be especially helpful.

I also want to revisit the current into-error.rs example with this in mind and see whether it can be expressed more clearly as a flow problem rather than an error-recovery problem. I will share the result once I have something concrete.

If we do decide that move semantics should be supported, then I think the next step is to discuss that explicitly and design it properly for intermediate frames as well, together with the API tradeoffs that follow.

[andylokandy]

As a follow-up, I rewrote the current into-error.rs example without into_error().

Instead of encoding partial progress in Err(HumanError::Partial(_)), the example now returns Result<Answer, HumanError>, where Answer lives on the success side:

pub fn run(question: String) -> Result<u64, AppError> {
    let answer = human::answer(question).or_raise(|| AppError)?;
    Ok(answer.value())
}

pub fn answer(question: String) -> Result<Answer, HumanError> {
    if question == "what is my age?" {
        return Ok(Answer::Exact(23));
    } else if question == "what is the answer?" {
        return Ok(Answer::Partial(42));
    }
    bail!(HumanError::Fatal { question })
}

This keeps partial output in the Ok path and uses exn only for the fatal path where contextual reporting is actually needed.

This does not prove that move semantics are never useful, but it does reinforce my concern that at least some motivating cases are better modeled as flow problems rather than error-recovery problems. If a representative example in this repository reads more clearly without into_error(), that is at least some evidence that top-level move semantics may not belong on the main path.

[feefladder]

Thanks @feefladder, this is helpful.

I think the symmetry point is important here.

Deref is top-level in the sense that it operates on Exn<E>, but borrowed access does not stop at the root because users can still walk frame() and downcast_ref() into erased intermediate frames. So the current borrowed story is not actually root-only.

into_error(), on the other hand, is root-only with no corresponding story for intermediate frames. To me, that suggests a more fundamental asymmetry: either we support move semantics with a coherent story for both top-level and intermediate frames, or we do not support move semantics as a first-class capability at all.

flawless logic. I do think the crate is very stable as-is and it'd only be into_frame, into_children and frame.into_error for full traversal (changing exn.into_error->exn.into_frame().into_error()).

That leads to the bigger question, which is really about the role of exn. Should exn primarily be an error view, a report, a contextual backtrace, or should it grow toward a more general-purpose error framework that also carries owned recovery semantics? My current intuition is still closer to the former.

I would say contextual backtrace with an opinion on error handling. That opinion leads to "Aah, why can't I do ugly stuff I can do with a normal Result<T, E>?", where the answer is: "because it's ugly and works better in a way you're not used to." Just like how Rust "forbids" mutating a &. However, if it is a contextual backtrace and nothing more, then I think it should add functionality (error tree walking and recovery), not remove it (top-level error move semantics).

currently exn is like:

• contextual backtrace
• Error tree walking
  I may want to add:
• No functional regression from "normal" Result<T,E>
  but my problems are theoretically solved now. Framing the role of exn as the above, I think it limits the scope and reduces friction of exn-ifying a codebase. Now the question is: Should that friction actually be there, because it nudges people in the "right" direction?

I also have a broader concern which may be independent of exn: if Result<T, E> is expected to return partial data in the Err branch, that may sometimes be better modeled as part of the normal control flow rather than as error handling.

Ah, just like how 206 is also a success code in stead of failure.

This is only my current view, and I do not want to overstate it, since there may well be real cases where this is hard to avoid. So far, though, I have not personally run into many examples that clearly require move-based recovery in error handling itself. Real-world examples here would be especially helpful.

I haven't used it in any code yet, but a real-world example of move-based recovery could be of a poisoned mutex? That is clearly an error, but also the contained struct may be expensive to Clone or even impossible. At current, stdlib won't be able to Exn their mutex errors.

I don't think there's any current examples of deeper error-recovery-with-move-semantics, because walking the error chain is a concept I first saw here.

As a follow-up, I rewrote the current into-error.rs example without into_error().

Instead of encoding partial progress in Err(HumanError::Partial(_)), the example now returns Result<Answer, HumanError>, where Answer lives on the success side:

pub fn run(question: String) -> Result<u64, AppError> {
    let answer = human::answer(question).or_raise(|| AppError)?;
    Ok(answer.value())
}

pub fn answer(question: String) -> Result<Answer, HumanError> {
    if question == "what is my age?" {
        return Ok(Answer::Exact(23));
    } else if question == "what is the answer?" {
        return Ok(Answer::Partial(42));
    }
    bail!(HumanError::Fatal { question })
}

This keeps partial output in the Ok path and uses exn only for the fatal path where contextual reporting is actually needed.

This does not prove that move semantics are never useful, but it does reinforce my concern that at least some motivating cases are better modeled as flow problems rather than error-recovery problems. If a representative example in this repository reads more clearly without into_error(), that is at least some evidence that top-level move semantics may not belong on the main path.

Thanks! I'll have to think about using this in my code though... It will need a bit of a redesign, because there's another path, let's say answer_absolute in which partial results are errors that want context. Maybe refactoring into success will actually make my code nicer. I was thinking of a struct with an error_for_status function, which solves the "other path" problem. Will come back after the refactor.

closing thoughts:

• thanks for the feedback and helpful, insightful elaborations, that's great!
• what about mutex?
• most of my intuition in my codebase at this point screams "it's an error", and that takes time to change.