Errors

Atoll represents absence and fallibility as explicit values.

maybe_user: User? = None
loaded: User ! LoadError = load_user(id)

There is no null literal and no exception syntax. The two fundamental containers are:

• Option[T], written T?, containing Some(T) or None;
• Result[T, E], written T ! E, containing Ok(T) or Err(E).

Both are ordinary enums with additional propagation and recovery syntax.

Chapters

• Option covers absence, construction, patterns, safe access, and fallback.
• Result covers explicit success and failure values.
• Error Types defines named error variants and fallible function contracts.
• Propagation specifies postfix ? for Option and Result.
• Catch handles or converts the error side.
• Error Unions combines several declared error domains without wrapper variants.

Total handling

Atoll’s core prelude does not expose panic-style unwrap or expect operations. A program handles a value by:

• matching every case;
• using a total fallback;
• transforming the successful payload;
• converting absence to an error;
• propagating through a compatible function boundary.

label := maybe_label.unwrap_or("untitled")

match load_user(id) {
    Ok(user) => show(user)
    Err(error) => show_error(error)
}

Typed handling makes failure behavior part of ordinary control flow and static API design.

Boundaries

Public functions should state stable success and error types.

fn load_user(id: int): User ! LoadError {
    // ...
}

Internal functions can infer fallibility from error and propagated ? sites, but inference should not hide an intentionally stable external contract.

The legacy docs also describe automatic logging and framework-specific top-level handlers. Those are not universal language semantics. Logging, retries, HTTP mapping, and process supervision belong to the host or application layer.