[chaorace]

Regarding citation #1: I'm a Rust learner myself, so this is something that's rather salient for me. What do you think about the "boxing errors[1]" approach? This strikes me as one possible way you could bubble up dependency errors without being forced to deal with type conversions.

[1]: https://doc.rust-lang.org/rust-by-example/error/multiple_err...

[iudqnolq]

When I said

> I now think you should either expose only a string message your user can just show their end user or an error that's much more specific so they can write code that intelligently responds to it.

a boxed trait object is the main way to implement an error that merely conveys a string message.

[chaorace]

I see, thanks for the response! I guess you're looking for something more deterministic so you can more effectively pattern match against the error's type?

[iudqnolq]

I think both are very good options. In a lot of cases it's not useful to deterministically match against the error type. The classic example of this is an application that's just going to pop up an error box, but this applies whenever your consumer can't fix the error even if you tell them specifics. In that case it's a significant waste of time to go beyond the boxed trait style (but anyhow or eyre add nice frills on top of a boxed trait).

Edit: Realized it might not have been clear that "boxed error" and "all you get are a string message" refer to the same thing. While you can try and convert a trait object to a specific type at runtime it's a crude and ugly approach that suggests that trait object should have been something else to start with. The main thing you do with a Box<dyn Error> is ask it for a Display message.