Mixing stringly-typed errors with structured errors?

[Enet4]

At #373, the subject of combining stringly-typed errors with structured errors was brought up.

Combining stringly-typed errors with structured errors is something that I expect most people will not want to do it (or for long). I'd be happy (but surprised) to learn that isn't the case. I assume that people that like stringly-typed errors tend to stick to anyhow. I assume it's when deciding to migrate towards structured errors that the combination of the stringly-typed and structured errors makes the most sense.

SNAFU has a strong stance on this, suggesting that such stringly-typed errors only make sense as a temporary measure before turning everything into structured errors. However, this feels strikes a bit too strongly against practical use cases of having an enum which may have both kinds without the intent to refactor later.

What other cases of mixing static and dynamic error types have you stumbled upon in practice? Can these be resolved or mitigated in some other way? I will post my own use case below.

[Enet4]

The dicom-encoding crate includes pixel data decoding and encoding adapter traits which are expected to be implemented by third-party crates. Implementers have to return errors through specific error types such as DecodeError.

#[derive(Debug, Snafu)]
#[non_exhaustive]
#[snafu(visibility(pub), module)]
pub enum DecodeError {
    /// A custom error occurred when decoding,
    /// reported as a dynamic error value with a message.
    ///
    /// The [`whatever!`](snafu::whatever) macro can be used
    /// to easily create an error of this kind.
    #[snafu(whatever, display("Error decoding pixel data: {}", message))]
    Custom {
        /// The error message.
        message: String,
        /// The underlying error cause, if any.
        #[snafu(source(from(Box<dyn std::error::Error + Send + Sync + 'static>, Some)))]
        source: Option<Box<dyn std::error::Error + Send + Sync + 'static>>,
    },

    /// Input pixel data is not encapsulated
    NotEncapsulated,

    /// A required attribute is missing
    #[snafu(display("Missing required attribute `{}`", name))]
    MissingAttribute { name: &'static str },
}

It combines structured variants with a custom stringly-typed message, because while some categories of errors can be predicted across decoders, the full set of errors which may come from a given implementation is unpredictable.

I cannot use a generic error type in this scenario, and if I made it just return a fully opaque error, I would be losing the opportunity for consumers and implementers to take advantage of the more specific variants.

[shepmaster]

SNAFU has a strong stance on this

At least the author of SNAFU has a strong stance — I'm not sure how much that opinion has leaked out into the released code. As mentioned, I'm happy to hear how others use it.