Error Handling Rules

unwrap-in-production

Severity: Warning

Detects .unwrap() calls in non-test code. Using .unwrap() in production can cause panics at runtime.

// Bad
let value = some_option.unwrap();

// Good
let value = some_option.context("expected value to be present")?;

panic-in-library

Severity: Error

Detects panic!(), todo!(), and unimplemented!() in library crates. Libraries should return Result instead of panicking.

// Bad
pub fn parse(input: &str) -> Config {
    panic!("not implemented");
}

// Good
pub fn parse(input: &str) -> Result<Config, ParseError> {
    Err(ParseError::NotImplemented)
}

box-dyn-error-in-public-api

Severity: Warning

Detects Box<dyn Error> in public function signatures. Public APIs should use concrete or well-defined error types.

result-unit-error

Severity: Warning

Detects Result<T, ()> return types. Using () as an error type discards error information.