SDK: errors
Every failed call rejects with a PithyxError. Daemon problems pass through unchanged; the sdk.* codes come from the connection between app and desktop. Every code is in the error reference.
Generated from the TSDoc comments of @pithyx/sdk 1.0.0-rc.9 at build time; the text below the headings is the comment in the source.
Classes
Section titled “Classes”PithyxError
Section titled “PithyxError”The error every failed SDK call rejects with. It carries the problem’s fields, so an app branches on code and
translates it itself; message is the English detail, or the code when there is none.
Example
Section titled “Example”try { await app.storage.set('draft', draft);} catch (error) { if (error instanceof PithyxError && error.code === 'app.storage.too_large') { showTooLarge(); } else { await app.ui.showError(error); }}Extends
Section titled “Extends”Error
Implements
Section titled “Implements”Constructors
Section titled “Constructors”Constructor
Section titled “Constructor”new PithyxError(problem): PithyxError;An error from a problem, as the SDK builds it from a desktop or daemon answer.
Parameters
Section titled “Parameters”| Parameter | Type | Description |
|---|---|---|
problem |
Problem |
The problem’s code, params, detail and request id. |
Returns
Section titled “Returns”Overrides
Section titled “Overrides”Error.constructor;Properties
Section titled “Properties”readonly code: string;Stable code, area.object.reason, for example fs.entry.not_found.
Implementation of
Section titled “Implementation of”params
Section titled “params”readonly params: Record<string, unknown>;Values for the translated message, for example { permission: 'files.read' }.
Implementation of
Section titled “Implementation of”detail?
Section titled “detail?”readonly optional detail?: string;English fallback text.
Implementation of
Section titled “Implementation of”requestId?
Section titled “requestId?”readonly optional requestId?: string;The request id for support, when the daemon was involved.
Implementation of
Section titled “Implementation of”Methods
Section titled “Methods”toProblem()
Section titled “toProblem()”toProblem(): Problem;The plain problem, for sending it over a transport.
Returns
Section titled “Returns”The problem without the Error parts.
Interfaces
Section titled “Interfaces”Problem
Section titled “Problem”A problem as it travels between desktop and app: RFC 9457 fields the Pithyx API uses.
Properties
Section titled “Properties”code: string;Stable code, area.object.reason.
params
Section titled “params”params: Record<string, unknown>;Values for the translated message.
detail?
Section titled “detail?”optional detail?: string;English fallback text.
requestId?
Section titled “requestId?”optional requestId?: string;The request id for support, when the daemon was involved.
Type Aliases
Section titled “Type Aliases”SdkErrorCode
Section titled “SdkErrorCode”type SdkErrorCode = (typeof sdkErrorCodes)[number];A code of the SDK’s own transport errors, translated under errors.sdk.*.
Variables
Section titled “Variables”sdkErrorCodes
Section titled “sdkErrorCodes”const sdkErrorCodes: readonly [ 'sdk.method.unknown', 'sdk.request.invalid', 'sdk.request.timeout', 'sdk.transport.closed', 'sdk.protocol.unsupported', 'sdk.transfer.cancelled', 'sdk.backend.endpoint_unknown', 'sdk.backend.unreachable',];Codes the SDK itself can produce. Codes of the daemon API come through unchanged and are strings as well.
Functions
Section titled “Functions”isProblem()
Section titled “isProblem()”function isProblem(value): value is Problem;Whether a value has the shape of a problem (RFC 9457 fields code and params).
Parameters
Section titled “Parameters”| Parameter | Type | Description |
|---|---|---|
value |
unknown |
Anything, for example a caught error or a parsed response body. |
Returns
Section titled “Returns”value is Problem
Whether value.code is a string and value.params an object.