error-stack: Is there any way to clone error_stack::Result?

[jrmoulton]

Both T and E implement Clone but I can't clone a Report. Is there any way to do this?

[TimDiekmann]

No, a Report cannot be cloned as the errors inside of Report don't necessarily implement Clone. This would require a bound T: Clone on any operation on Report (i.e. all contexts and attachments would need to be Cloneable) but it's very common that errors don't implement Clone. As a very prominent example, std::io::Error does not implement Clone. Adding a Clone bound would imply that many errors would not work with error-stack anymore.

[jrmoulton]

Interesting. that makes sense. Thanks for clearing that up!

[AriaFallah]

@TimDiekmann hmm running into this now (caching a function output that returns a result), and I'm really torn on how to solve this. Do you have any ideas on what makes sense?

Let's say for my project, I don't really care that errors don't impl clone, is there an easy fix? Like I wouldn't mind a version of .change_context that just wrapped anything not clone like std::io::Error into an Arc

Or if I return an Arc is there an easy way to use the frames from that to reconstruct another report?

[TimDiekmann]

I'm not entirely sure I understand you issue. What stops you just putting the Result<_, Report<_>> into an Arc? Could you give an example?

[AriaFallah]

@TimDiekmann thanks for replying so quickly! It's super appreciated! Been using the library for maybe 3 years now very happily and telling everyone about it :).

What stops you just putting the Result<, Report<>> into an Arc

Well once I do that, I can't .change_context on the report because it's mut self right? Is there something I can do with an immutable Report object I'm missing? Well other than .to_string() it

Could you give an example?

Hmm maybe this isn't complete enough, but let's say I have a function like

async fn do_expensive_query() -> Result<QueryResult, Report<ThingError>>

I can cache the result by slapping something like a #[memoize] on top (which is a bunch of ceremony around a OnceLock + Hashmap<args, result> + Mutex). But I can't actually do that because the Report isn't Clone.

Maybe this is just Rust, but I don't love how the semantics regress once caching is introduced.

[TimDiekmann]

It's super appreciated! Been using the library for maybe 3 years now very happily and telling everyone about it :)

Very glad to hear!
Also, we'd be very interested in some experience. We don't actively develop new features currently for error-stack (even though there are some things I'd love to see), but having a sense on how other users use error-stack would definitely help. In particular if you actively use it for three years (wow, it's been so long since I have written this library?). We can also create a new discussion on user experience which later can be developed into best-practices. I can imagine that people use the library differently.

Well once I do that, I can't .change_context on the report because it's mut self right? Is there something I can do with an immutable Report object I'm missing? Well other than .to_string() it

Ah, yes, I see the issue. Unfortunately, I don't know what the best way would be to handle it. At least not if you want to further process it with .change_context. With the current implementation it would not be possible unless you want to store the raw ThingError instead of Report<ThingError>. (.change_context is implemented on a consuming self, so you'd need to move out the result out of the Arc)

I could imagine a few different ways how to implement this (I'd be interested in a solution as well btw.), but none of them is easy.

• Require the context to implement Clone: Simple not possible. Too many errors don't implement it (in particular errors coming from the OS, such as io::Error)
• Somehow store a clone function pointer for each frame if it exists and manually clone the frame stack (the internal representation of a Report). But this has several issues:
  • How to detect if something is clone-able?
  • How to "enable" the Clone function? We would need to track this somehow in the type system (panic is probably not an option)
  • Overhead of a function pointer per frame (probably not a super big deal as everything is boxed to keep Report small (a Report is guaranteed to have the same size as a thin pointer)
• Enable cloning through an internal Rc or Arc
  • Overhead when dealing with Report (runtime for creating Rc/Arc + size per frame)
  • Arc or Rc? In most cases you only need Rc, unless you don't
  • How would mutable access to the context work? Would it behave like Arc::into_inner?
  • @indietyp did some experimentations on optimizing the backing frame stack by replacing it with a vector, this might be useful here: H-3330: Optimize allocation behavior during report construction #5161. It's quite outdated and would need some love (and I know he's super busy at the moment), but at least it's something.
• Allow handling of Arc<Report<_>> and Rc<Report<_>>
  • that's just a wild idea and I don't know if or how this would work, but for completeness it's probably worth
• Implement some Report<Arc<_>> handling
  • unlikely to work because of the orphan rule for a good reason, Arc<T> could implement Error if T: Error
  • Would change the semantic of a Report, which I dislike

If you have any other ideas please feel free to share them as well. The third option (using an internal Arc) would probably the only possible solution as of now. It at least would enable us to generally allow implementing Clone on a Report, but it would not be easy and sadly I don't see myself being able to allocate time for that now. As I said, I'd be interested in a solution as well, but pretty much bailed the topic because it's ... complicated.

Maybe @indietyp also has a few ideas or comments on this.

Generally, I don't see this being possible right now. A few ideas to solve your issue (none of them is great):

• Store the ThingError, not Report<ThingError> -> Loses a lot of contextual information
• Don't store Result<T, Report<E>> but T. If you encounter an error handle it immediately.
  • I'd question how useful it is to store the full Result because you'd need to always handle the error. There might be a simpler way but handle the error immediately.
  • If the result should be evaluated lazily (and you need it more than once) you might want to create a small enum { Evaluated(T), Unevaluated(Result<T, Report<E>>), Taken }. Then you can replace the Unevaluated variant with either Evaluated(T) or consume the Report<E> and handle the error.
• (if you only need the result once) Put it into an Option<_> and .take() it later

Maybe this is just Rust, but I don't love how the semantics regress once caching is introduced.

That's definitely not only in Rust. But in Rust it's easier to spot ;)
Of course, you could always memcpy the error or always use reference counted errors, but the underlying issues with caching remain the same. In particular when it comes to mutations.

[AriaFallah]

Require the context to implement Clone: Simple not possible. Too many errors don't implement it (in particular errors coming from the OS, such as io::Error)

Maybe this is too controversial lol, but could we not just Arc<> any error that isn't Clone? Like the errors that actually make up the report, I cannot think of a reason to mutate them ever. Maybe for all consumers of this library this is not acceptable because they don't want that overhead, but idk I'd be happy to .map_err(Arc::new) anywhere I have a error cloning problem

We can also create a new discussion on user experience which later can be developed into best-practices. I can imagine that people use the library differently

Yeah for sure. I don't know how much I have to add since my usage isn't crazy advanced. I think moreso I have more questions than answers e.g. stuff I still think about even today in my current project: when to use struct error vs enum error or, I just started using spantraces, and they automatically capture a lot of stuff I used to put into errors before around execution context when things went wrong...so now what data do I put into my error types.

Nothing super coherent. Maybe one day I write up a blog post when I feel more confident about the usage. The library is for me the ultimate nice bridge between something like an anyhow and thiserror (I use thiserror with it though lol) where I get really good error context and can step down into the lower level error handling variants or just keep everything coarse grained.