Skip to main content
The Figranium Kotlin SDK raises one error type for every failure: FigraniumException. It extends java.io.IOException, so you can catch it alongside transport errors in a single catch block. You can branch on status for HTTP semantics, on code for machine-readable categories, and on message for a human-readable description.

FigraniumException shape

Figranium.kt
Because FigraniumException extends IOException, OkHttp transport failures (such as SocketTimeoutException or UnknownHostException) and Figranium API errors can be handled together or separately depending on how you structure your catch blocks.

Basic handling

Client.kt

Fields

The HTTP status returned by the Figranium server, if a response arrived. 0 when the request never reached a status, such as a network failure, DNS error, or cancelled request.
Server-provided machine-readable error code, taken from the response body’s error field. Also used for SDK-generated conditions:
Free-form value from the response body’s details or detail field. Typically an object describing which validation failed, which record was missing, or which field was invalid.
Value of the x-request-id response header, when the server or a proxy sets one. Include this in bug reports to make server-side logs easier to correlate.
Human-readable description of what went wrong. For server errors, this is taken from the response body’s message or error field. For SDK-generated errors, it describes the condition (for example, “Figranium returned an empty response”).

Branching on status

Client.kt

Transport failures

When the request never gets a response (server unreachable, DNS failure, TLS error), OkHttp throws an IOException. Because FigraniumException extends IOException, you can handle both Figranium errors and transport errors in one catch, or distinguish them by type.
Client.kt

Timeouts and cancellation

When a request exceeds the configured timeout, the underlying OkHttpClient throws an IOException (such as SocketTimeoutException). When the consuming coroutine is cancelled, the active Call is cancelled and a CancellationException is thrown.
Client.kt
Cancelling the consumer of a flow stream also cancels the underlying Call.
Always check e is FigraniumException before reading SDK-specific fields. Unknown errors should be rethrown so they bubble up to your global error handler.

Request Options

Set per-call timeouts and headers.

Streaming

Consume Server-Sent Events and handle stream-specific errors.