Home About Documentation Templates Examples Showcase GitHub
Theme

Scripting & runtime · errors

Recover from operational failures deliberately.

v4.6 lets external/operational failures propagate to a caller that chooses to handle them. Programmer, invariant, and policy failures stay fatal, because local recovery would hide a defect or cross an authority boundary.

try {
    lib := ffi_open("./libmath_helpers.so")
} catch(err) {
    print(err.code)     // ffi.library_load_failed
    print(err.message)
}

What is recoverable

Recoverable operational failures include FFI loader and symbol lookup failures, import-source acquisition failures, approved filesystem and FileValue backend failures, stream backend failures, and JSON parse/schema rejections. Each carries a structured diagnostic: a stable code, a human message, and a disposition.

try {
    text := cat("missing.txt")
} catch(err) {
    print(err.code)     // io.open_failed
}

try {
    import("missing.f")
} catch(err) {
    print(err.code)     // io.import_source_unreadable
}

What stays fatal

Malformed programs, invalid runtime use, authority/privacy violations, and internal invariants are not catchable. This is a runtime error-handling contract, not a general exception system — there is no general throw of arbitrary values.

Structured diagnostic outcomes

Failures expose structured outcomes (code, disposition, source origin, and diagnostic frames) rather than only a message string, so script, template, import, and embedding paths report consistent, machine-readable errors. The Error value itself remains interpreter-only and does not cross the embedding/JSON/binding boundary; embedding surfaces the structured diagnostic instead.