ParseIntError and ParseFloatError does not allow to introspect the cause

[nagisa]

The only way to introspect reason of .parse failure is to compare to error messages returned by description or use the following code snippet:

let overflow = "1231123123123123".parse::<u32>().err().unwrap();
let underflow = "-1231123123123123".parse::<i32>().err().unwrap();
match "999999999999".parse::<u32>() {
    Ok(n) => println!("{}", n),
    Err(ref e) if *e == overflow => println!("Overflow"),
    Err(ref e) if *e == underflow => println!("Underflow"),
    _ => panic!("wow, no introspection, very convenience")
}

[alexcrichton]

Note that this was purposefully done to avoid adding extra #[stable] surface for now. It should be able to expose this information through an enum in the future, for example.

[steveklabnik]

Triage: no change here.

@rust-lang/libs is the intention still to change this to an enum of some kind in the future?

[Seeker14491]

Any reason to postpone this further?

[BurntSushi]

@Seeker14491 I don't think it's postponed. I think someone just needs to propose an API?

[phungleson]

Hey, we already have an enum IntErrorKind, just want to check if anything still need to be done to make it pub

rust/src/libcore/num/mod.rs

Lines 2769 to 2774 in fc02736

	enum IntErrorKind {
	Empty,
	InvalidDigit,
	Overflow,
	Underflow,
	}

[gypsydave5]

I just brushed up against this issue while demoing the guessing game example from the Rust Book - seemed like an easy thing to show off matching on the error kind, but turned out not so much!

[frontsideair]

I also wanted to match IntErrorKind::Empty in the number game to abort on EOF, turned out to be impossible.

[sfackler]

@frontsideair you can just check if the string's empty before parsing, right?

[frontsideair]

I guess, but it was a fun exercise in pattern matching.

[dtolnay]

I see that checking for empty has come up in the context of the guessing game tutorial. Could somebody make a list of use cases from real code that needs to be able to distinguish between the following other ParseIntError cases?

• invalid digit
• number too large to fit in target type
• number too small to fit in target type

In the event that empty is the only one we ever need to introspect for, I would prefer to close this and instead recommend to check == "" before parsing.

[ranma42]

It can be convenient to distinguish too large/too small numbers when accepting configuration parameters that the code will later sanitize by clamping to a valid range. Specifically, they make it possible to perform saturation of the parsed value before it is passed on.

Example: the valid range of offsets is -10..+10, therefore the application stores it in an i8. When the value it outside of the -10..+10 range the app would like to warn the user and proceed with the nearest legitimate value.

Without the ability to discriminate if the number is too big/small, it is not possible to determine what is the nearest legitimate value.