UzoError and branching on its code, which doesn’t change between releases even if the message wording does.
Early release. This is published in
@uzolabs/sdk 0.2.0 on npm and you can use it today. The API may change before 1.0, so pin the version.How errors work
Every error the SDK throws extendsUzoError, which extends JavaScript’s Error. Each one has:
string
The class name, such as
"ExplorerError".string
A stable code, such as
"EXPLORER_ERROR". Branch on this, not on message.string
A sentence that says what went wrong and what to do next.
unknown
The underlying error, when there is one. For example, the
fetch failure behind an ExplorerError.handle-errors.ts
Output
Errors thrown in 0.2.0
UnsupportedChainError
Cause: a chain ID other than
677 (BOT Chain) or 968 (BOT Chain Testnet). Often this is the user’s wallet being on another network.
Fix: pass 677 or 968. In a dapp, ask the user to switch networks before you call the SDK. See Connect a wallet.
InvalidAddressError
Cause: the input isn’t a 0x-prefixed, 20-byte hex string. Common causes are a truncated paste, a missing
0x, or an ENS-style name.
Fix: pass a full address. Mixed-case addresses are accepted and checksummed for you.
ExplorerError
Reserved for planned modules
These classes are exported in 0.2.0 so you can write handlers now, but nothing throws them yet. They’re for the planned modules. Their fields come from the 0.2.0 source. When they’ll be thrown may change.Related
Types
Exported TypeScript types.
Explorer client
The main source of runtime errors in 0.2.0.