match_wild_err_arm: Err(_) is not wild

[tspiteri]

The match_wild_err_arm lint documentation compares Err(_) to Java with catch(Exception), but it is nothing like it. While the Java version does catch all exceptions, the Rust version can only catch one error type.

Even the warning message provided is misguided. It recommends matching each error separately, but there is only one error to match.

This makes this lint not really helpful. Or am I missing something?

I don't get it either. Based on the logic in this lint, we should also warn on expect and unwrap calls since they do the same thing.

[flip1995]

That Result<T, E> can only have one error type is true. But the error type can be an enum. For example

enum Error {
    InternalError,
    WrongArguments,
    FileNotFound,
    ...,
}

fn main() {
    match run_my_program() {
        Ok(_) => println!("yay"),
        Err(_) => panic!("nay"),
    }
}

Would result in the error message "nay" no matter what the error was. If you have only one error Type you can handle this by an exhaustive match:

match run_my_program() {
    Ok(_) => println!("yay"),
    Err(Error::InternalError) => panic!("oops"),
    Err(Error::WrongArguments) => panic!("{}", help),
    Err(Error::FileNotFound) => panic!("File {} does not exist", file),
    ...
}

This is better, because it gives a custom error message dependent on the type of the error. Panicking on a known error is still probably something you don't want to do and you may want to handle errors with crates like failure or similar.

---

That said, the documentation should be more specific about what the lint wants from the programmer.

[flip1995]

we should also warn on expect and unwrap calls

IMHO this isn't quite the same. If you write expect or unwrap somewhere you are (should be) sure, that the call never panics. If you write a match over Ok and Err you expect that something can go wrong and want to deal with this. But then you can do it right and be more specific in the error messages.

Maybe this lint can mention something like:
"If you're sure that this doesn't error, use .expect(msg)"

---

On expect vs unwrap see #1921.

[tspiteri]

I can see that when the error is an enum it can be helpful. If that is the case, there are some false positives. For example

enum Radix {
    Digits(i32),
    DigitsLetters(i32),
    AltDigits(i32),
    AltDigitsLetters(i32),
}
fn classify(radix: i32) -> Result<Radix, i32> {
    match radix {
        2..=10 => Ok(Radix::Digits(radix)),
        11..=36 => Ok(Radix::DigitsLetters(radix)),
        -10..=-2 => Ok(Radix::AltDigits(-radix)),
        -36..=-11 => Ok(Radix::AltDigitsLetters(-radix)),
        _ => Err(radix),
    }
}
// Panics if magnitude of radix < 2 or > 36
fn foo(n: u32, radix: i32) {
    match classify(radix) {
        Ok(Radix::Digits(radix)) => print_digits(n, radix),
        Ok(Radix::DigitsLetters(radix)) => print_digits_letters(n, radix),
        Ok(Radix::AltDigits(radix)) => alt_print_digits(n, radix),
        Ok(Radix::AltDigitsLetters(radix)) => alt_print_digits_letters(n, radix),
        Err(_) => panic!("wrong argument"),
    }
}

In this case I'd say the warning is a false positive.

So the only time the warning is helpful is when the error type is an enum. Why not warn only in that case then? It would make it easier to give a helpful message too, because then it would make sense to ask for matching each error variant separately.

[Manishearth]

Actually, I'd go further and say that this lint should be pedantic, in addition to making it only warn for public enums.

[elichai]

Agreed, this lint just failed my CI(https://travis-ci.org/github/elichai/stdio-override/jobs/689175682) and the code there is reasonable, I don't always want to use expect for various esthetic reasons.
and as people said before me Java's catch is really different, because the exception could come from anywhere and new types of exceptions can be added in the future.
in Rust the "exceptions"(aka Errors) are safely typed. so if a function returns for example Result<T, ()> there's nothing smart to "match on" and no new errors can be added without a breaking change (the same is also for error structs, or non-exhuastive error enums)