Fatal Errors
A fatal error aborts the program on an unrecoverable condition rather than returning an error to the caller. Fatal errors are reserved for bugs and invariant violations — situations the program is not expected to handle at runtime.
You can trigger one explicitly with Panic from the Core package, which prints a diagnostic message and the call-site location to standard error and exits with code 1:
import Core::Panic;
Panic("unreachable: unknown variant");
Several documented operations also fail fatally:
- Integer overflow in debug builds raises a fatal error; release builds wrap instead (see Signed Integer overflow behaviour).
- Narrowing character casts raise a fatal error when the value is out of range; use
as?to getnullinstead (see Character Types). - Casting
NaNorInfto an integer raises a fatal error in debug builds (see Floating-Point Types).
For conditions a caller is expected to recover from, return a Result instead.
See Also
- The
ResultType — the recoverable-error alternative Panic— the standard-library function that triggers a fatal error- Intrinsic Constants — the
#source.file/#source.linevalues reported at the call site
The Result Type
The standard approach to recoverable errors uses return-type encoding with a Result type. A function that can fail returns Result<T, E>, where T is the success value and E is the error.
Overview
The foreign function interface (FFI) lets Rux call functions defined outside the language — typically in C / C++ libraries — and exchange data with them. Each part of the FFI has a dedicated chapter: