Cannot use `trait Custom: std::error::Error` as boxed source due to sealed `AsDynError`

[Byron]

Thanks for this crate :). I use it all the time and even switched from quick-error to it because it seemed to have no real disadvantages.

My problem is probably most concisely described with code (playground):

use thiserror; // 1.0.37

/// An error which can tell whether it's worth retrying to maybe succeed next time.
pub trait IsSpuriousError: std::error::Error {
    /// Return `true` if retrying might result in a different outcome due to IO working out differently.
    fn is_spurious(&self) -> bool {
        false
    }
}

#[derive(Debug, thiserror::Error)]
#[error("works as AsDynError is implemented for std::error::Error in various ways")]
pub struct WorksError {
    source: Box<dyn std::error::Error + Send + Sync>
}

#[derive(Debug, thiserror::Error)]
#[error("can't work since AsDynTrait isn't implemented for IsSpuriousError and can't be implemented by author either")]
pub struct FailsError {
    source: Box<dyn IsSpuriousError + Send + Sync>
}

fn main() { }

Due to the sealed and private trait AsDynError I am unable to have custom traits as Error which derive from std::error::Error. Probably there is a very good reason that I am missing and I'd be happy to learn.

The motivation for such trait is cargo which will retry if it thinks the encountered error is spurious. I thought it would be nice if the respective gitoxide errors could say so via is_spurious().

The workaround is boilerplate heavy and nearly undoes the benefit of such a trait as one can implement IsSpuriousError for WorksError itself, downcasting to the concrete Error types of the crates to call the is_spurious() implementations.

Could there be a better way?

Thanks for your advice 🙏

[dtolnay]

Ignoring AsDynError for a second, what would a handwritten std::error::Error implementation for FailsError look like, in your opinion?

[Byron]

The error types I am dealing with look more like this and removing thiserror from the equation will definitely be more complex than doing a few downcasts.

If there is other solutions than to not use thiserror i'd be happy to try contributing. Otherwise it's certainly OK to close this issue, now that I have written the downcast-workaround I think it's OK to keep as well.

Thanks again

[Byron]

Another possible action would be to address the error message, here repeated directly from the playground:

error[[E0599]](https://doc.rust-lang.org/stable/error-index.html#E0599): the method `as_dyn_error` exists for struct `Box<(dyn IsSpuriousError + Send + Sync + 'static)>`, but its trait bounds were not satisfied
  --> src/main.rs:20:5
   |
4  |   pub trait IsSpuriousError: std::error::Error {
   |   --------------------------------------------
   |   |
   |   doesn't satisfy `dyn IsSpuriousError + Send + Sync: AsDynError`
   |   doesn't satisfy `dyn IsSpuriousError + Send + Sync: Sized`
...
20 |       source: Box<dyn IsSpuriousError + Send + Sync>
   |       ^^^^^^ method cannot be called on `Box<(dyn IsSpuriousError + Send + Sync + 'static)>` due to unsatisfied trait bounds
   |
   = note: the following trait bounds were not satisfied:
           `Box<dyn IsSpuriousError + Send + Sync>: std::error::Error`
           which is required by `Box<dyn IsSpuriousError + Send + Sync>: AsDynError`
           `dyn IsSpuriousError + Send + Sync: Sized`
           which is required by `dyn IsSpuriousError + Send + Sync: AsDynError`

Rust as of 1.65 won't make it clear where the trait AsDynError is defined. Due to its official name I assumed it's in the standard library, and failing to find it there led to searching crates.io and lib.rs, to no avail. Only at last I thought that it then must be originating in thiserror (maybe something more experienced users will know right away) and found it here.

I don't know if this can reasonably be addressed in the Rust compiler, but since it is an implementation detail of thiserror it might be easiest to rename the trait so that it's clear what the users is or isn't supposed to do.

So far thiserror was absolutely wonderful and just worked with whatever I threw at it, which is why I'd love to smooth out this interaction with the library as well.

[dtolnay]

It does not seem that this is a scenario different users are commonly encountering. I think it's fine to leave impl Error for FailsError as something that needs to be handwritten rather than using the derive for it.