Document how to wrap an eyre::Report with a different error type

[TheButlah]

Wrapping a source error type as the cause of an eyre::Report is very straightforward with the wrap_err function. But suppose I have an eyre::Result<()> and want to convert it into a Result<(), ()> without discarding the helpful backtrace/spantrace from eyre? Is that even possible?

If it is, can it be documented?

[yaahc]

But suppose I have an eyre::Result<()> and want to convert it into a Result<(), ()> without discarding the helpful backtrace/spantrace from eyre? Is that even possible?

As stated and assuming by Result you mean std::result::Result, no, you definitely cannot convert an eyre::Result<()> to a Result<(), ()> without losing all relevant information. I think I may be misunderstanding what you mean, but based on what you wrote, you're essentially asking for Result<(), eyre::Report> -> Result<(), ()> which can be reduced to eyre::Report -> (), aka converting eyre::Report to the unit type. This a drop, and can only be accomplished by discarding the original eyre::Report. All relevant information to an error such as backtrace and spantrace are stored in the eyre::Report, not the Result. We cannot discard this Report type without losing all of that helpful information.

Now, if you meant "any arbitrary result-like type" when you wrote Result<(), ()>, then yes, that is potentially possible, though the API needed to do so is currently missing. I'd need to add a method like fn into_parts(self) -> (Box<dyn Error + Send + Sync + 'static>, Box<dyn EyreHandler>) which you could call to take the Handler out of an eyre::Report, which is likely where your backtrace and spantrace and other relevant context are stored, and then from there you could store that Handler in your own custom Result type and discard the error to replace it with a ().

[TheButlah]

you're essentially asking for Result<(), eyre::Report> -> Result<(), ()> which can be reduced to eyre::Report -> (), aka converting eyre::Report to the unit type

Yeah that sums it up pretty well and it makes sense why that would not be viable. I guess what I'm really looking for is a way to continue to have whatever error type E my Result is supposed to use, but still propagate the helpful backtrace info that eyre contains. I can create a new Report from my original error E but since its not a Report<E> I cannot access the wrapped error easily.

Perhaps adding type args to Result and having them default to Box<dyn StdError> would be a viable approach? and then add an accessor for the wrapped error (the direct child, not the bottom-most root of the error chain).

I can create a PR for it if that is helpful :) I think it should still be backwards compatible due to the default type argument

[yaahc]

I'm not sure I understand. Can you give me an example of what you're trying to do?

[TheButlah]

Wow I left this for a full year lol.

I believe what I was asking for was a way to propagate the information about the chain of underlying errors to other error error libs like thiserror.

I wanted to be able to use eyre in a library for prototyping easy errors, and then have a parent library that uses thiserror that handles error from all subsystems, some of which may be using eyre. But I didn't want to lose the helpful error chain.