Stop Calling .unwrap() on Your Config Loader (Rust File IO + serde JSON)

#rust #serde #json #errors

Day 25/90: The AppConfig Loader That Panicked on a Trailing Comma

90 Day Rust Challenge: Zero to Production

The first time a user shipped my tool a config file with a stray trailing comma, the whole binary went down. Not a message, not a fallback — a panic and a backtrace. The cause was a line I wrote without thinking, because it was a demo and demos always have valid input:

fn read_config(p: &str) -> AppConfig {
    let bytes = std::fs::read_to_string(p).unwrap();
    let parsed: AppConfig = serde_json::from_str(&bytes).unwrap();
    parsed
}

Two .unwrap() calls, two ways to crash. The first panics on a missing or unreadable file. The second panics on JSON that is invalid or does not match my struct.

Why these calls return Result

std::fs::read_to_string returns io::Result<String>, which is Result<String, std::io::Error>. serde_json::from_str returns a Result too. Both signatures are telling you, in the type, that the operation can fail — because reading a file you did not write, and parsing text you did not generate, can genuinely fail. Calling .unwrap() throws away the Err half and turns a normal error into a panic.

The fix is the ? operator. It returns the error to the caller instead of crashing:

use std::fs;

fn load_config(path: &str) -> Result<AppConfig, Box<dyn std::error::Error>> {
    let raw = fs::read_to_string(path)?;
    let config: AppConfig = serde_json::from_str(&raw)?;
    Ok(config)
}

In a real loader, those ? conversions would land in the thiserror enum from yesterday's post, so each error becomes a named variant instead of a stringly-typed blob.

The AppConfig struct and two serde attributes

You describe the shape once with two derives and serde generates the read and write code:

use serde::{Deserialize, Serialize};

#[derive(Debug, Serialize, Deserialize)]
struct AppConfig {
    name: String,
    host: String,
    port: u16,
    #[serde(default)]
    verbose: bool,
    #[serde(default)]
    retries: u32,
    #[serde(default)]
    max_conns: u32,
}

#[serde(default)] makes verbose optional. A config that omits it deserializes fine and the field becomes false. Without that attribute, a missing field is a hard missing field error. That one line is how you declare "optional" right on the field.

Round-trip: read, mutate, write

The full loop — read, deserialize, mutate, serialize with to_string_pretty, write — with ? on every fallible step:

use std::fs;
use std::error::Error;

fn bump_port(path: &str) -> Result<(), Box<dyn Error>> {
    let text = fs::read_to_string(path)?;
    let mut config: AppConfig = serde_json::from_str(&text)?;
    config.port += 1;
    let out = serde_json::to_string_pretty(&config)?;
    fs::write(path, out)?;
    Ok(())
}

fn main() {
    if let Err(e) = bump_port("config.json") {
        eprintln!("could not process config: {e}");
        std::process::exit(1);
    }
}

to_string_pretty writes the file with indentation so it diffs cleanly. Feed this a malformed file and you get could not process config: expected ... on stderr plus exit code 1, instead of a backtrace.

Streaming large files

from_str loads the entire file into a String, then parses it — fine for a config, wasteful for a big data file. from_reader over a BufReader parses straight from the stream:

use std::fs::File;
use std::io::BufReader;

fn load_big(path: &str) -> Result<AppConfig, Box<dyn std::error::Error>> {
    let file = File::open(path)?;
    let reader = BufReader::with_capacity(64 * 1024, file);
    let config: AppConfig = serde_json::from_reader(reader)?;
    Ok(config)
}

Use from_str when you already hold a string; use from_reader over a BufReader when you are reading off disk and the file might be large.

The rule I kept

.unwrap() on fs and serde_json calls is not error handling. It is a deferred panic that fires on the first imperfect input — and there is always a first imperfect input. Reading and parsing both return Result. The ? operator turns "the program died" into "the function returned an error the caller can read," and it costs one character.

DEV Community