How to get meaningful parsing error messages that include input string?

[fritzrehde]

I think the ParseError message should include the &str for which parsing failed, otherwise I have no clue where in the application the parsing failed/for which value it failed. Is it possible to enable this? If not directly in parse-display, how would I do this with Rust error handling in general (I use anyhow btw if that helps)?
Something like Failed to parse string "<string>" into type <type> would be awesome, if that is possible somehow.

Thanks for the awesome crate!!

[frozenlib]

At present, parse_display lacks the functionality to produce meaningful error messages.

I've personally faced scenarios where I wanted error messages to incorporate input strings, and would like to improve this.

However, it appears to be a common practice in Rust not to include input strings in errors.
This is the case for errors included in the standard library (e.g. std::num::ParseIntError), url crate (e.g. url::ParseError), and chrono crate (e.g. chrono::format::ParseError).

If an error contains an input string, String must be created from the input &str and included in the error, which is a performance disadvantage.
So, I believe this practice is appropriate.

For example, when parsing a huge string literal into the following type Value,

#[derive(FromStr)]
#[display("{0}")]
enum Value {
    Int(u32),
    Bool(bool),
    #[display("\"{0}\"")]
    Str(String),
}

The following is processed.

• ParseIntError is generated due to failure to parse Int(u32).
• ParseBoolError is generated due to failure to parse Bool(bool).
• Str(String) is generated.

If ParseIntError or ParseBoolError had contained an input string, a huge String would have been generated twice in vain.

However, seeing that the regex crate generates a clear error including the input string, it seems that it is not absolutely necessary not to include input string.

I wrote above that it appears to be common practice in Rust not to include input strings in errors, but more accurately, I feel that it is recommended that users be given the choice of whether or not to include input strings in errors.

For example, if the error in FromStr does not include input string, then by using context of anyhow, you can create a wrapper in which the error includes input string.

trait FromStrEx: Sized {
    type Err;
    fn from_str_ex(s: &str) -> Result<Self, Self::Err>;
}
impl<T: FromStr> FromStrEx for T
where
    T::Err: std::error::Error + Send + Sync + 'static,
{
    type Err = anyhow::Error;
    fn from_str_ex(s: &str) -> Result<Self, Self::Err> {
        s.parse()
            .with_context(|| format!("failed to parse `{}`", s))
    }
}
fn main() {
    println!("{:?}", u8::from_str_ex("500"));
    /*
	Err(failed to parse `500`
	
	Caused by:
        number too large to fit in target type)
    */
}

Still, I do not believe that this error message is the best one, and there might be cases where the choices are unnecessary.

So, in the future, parse_display would like to be able to generate errors with input string by specifying them in an attribute.
However, by default, I would like to generate errors without memory allocation.

(Note: While it's not possible to include input string in error message without memory allocation, type name can be incorporated.)

[fritzrehde]

Thanks for the elaborate answer. I understand your concern with the memory overhead, and I agree. However,
I think it should be possible for those willing to (I actually came up with that same anyhow context solution) to somehow enable explicit error messages that contain the input string. I'm not entirely sure how such customization would work in practice in Rust.
For now, I think it might be useful to add a section in the readme that explains the lack of input strings in error messages, and the reasoning you provided.
Also, I'm glad to help with the implementation of such an optional feature if you need it!