Failure Policies

Each operation family has its own FailurePolicy, independent of the others, defaulting to FALLBACK:

EasyConfig.holder(MyModConfig.class)
    .modId("mymod")
    .readFailurePolicy(FailurePolicy.FALLBACK)   // corrupt/invalid file → back it up, restore defaults
    .writeFailurePolicy(FailurePolicy.STRICT)    // save failure → throw EasyConfigException
    .updateFailurePolicy(FailurePolicy.FALLBACK) // invalid edit → discard, keep current state
    .create();

Use failurePolicy(policy) as a shorthand to set all three at once.

Policy	On failure
FALLBACK	Logs and degrades gracefully
STRICT	Throws EasyConfigException

Important distinction — recoverable failures vs. defects:

FALLBACK only suppresses recoverable failures — a corrupt file, a missing field, a validation rejection. Defects are always re-thrown regardless of policy. A defect is a programming mistake in the mod itself: a null mutator, a config model that violates Easy Config rules, a validator that throws an unexpected exception.

Every EasyConfigException carries a ConfigError code. Branch on the code rather than on message text:

try {
    holder.load();
} catch (EasyConfigException ex) {
    if (ex.error() == ConfigError.IO_LOAD_FAILURE) {
        // file is gone or unreadable
    }
}

Read fallback behavior: when FALLBACK handles a corrupt or invalid file found during create() or load(), the bad file is renamed to <filename>.corrupt-<timestamp> and the defaults are written in its place. The holder starts (or continues) in a clean state, and the player can recover their values from the backup.