Errors

Catch the typed error classes the SDK throws at public boundaries.

What validation cannot catch is thrown instead, as named classes that all extend BaseError, which is itself catchable with instanceof and carries a walk() helper for finding a specific class anywhere in a wrapped error’s cause chain. A wallet prompt someone declines raises UserRejectedRequestError; a write the chain rejects raises TransactionRevertError; a missing or locked wallet, an unreachable price server, and an unknown contract each have their own. Narrow with instanceof against the specific class your UI treats differently, fall back to instanceof BaseError to catch anything else the SDK throws, and re-throw what’s left over.

ValidationError is the one exception — it is what a Result’s error side carries from the validation rule sets and single-value validators, and it extends Error directly rather than BaseError, since validation never throws.

Sending a transaction and narrowing what comes back:

try {
  const hash = await sendTransaction(ctx, { transaction });
  return { hash };
} catch (error) {
  // Narrow with instanceof against the classes your UI treats
  // differently; fall back to a generic message for the rest.
  if (error instanceof UserRejectedRequestError) {
    return { error: 'cancelled by user' };
  }
  if (error instanceof WalletNotConnectedError) {
    return { error: 'connect a wallet first' };
  }
  if (error instanceof TransactionRevertError) {
    return { error: `reverted: ${error.message}` };
  }
  if (error instanceof BaseError) {
    return { error: error.message };
  }
  throw error;
}

Primary APIs

Classes

• BaseError — Base class for all Anvil SDK service errors.
• ConfigError — Base class for all Anvil SDK service errors.
• ContactSupportError — Error indicating that an internal SDK error has occurred, and the user should contact the support team with the provided code.
• ContractNotFoundError — This error is thrown if a contract address is requested by name but not found.
• HttpRequestError — SDK-specific HTTP error payload indicating the HTTP status of the failed request.
• InvalidArgumentError — This error is thrown if some operation has invalid values for one or more arguments.
• MaxRetriesExceededError — Error thrown when a retried operation exhausts all retry attempts without succeeding.
• NoBrowserWalletError — This error is thrown if, based on configuration, the SDK expects a browser wallet to exist and one is not found.
• PriceFeedNotFoundError — Error thrown when no single Pyth price feed can be resolved for a token: Hermes returned no feed for the token’s symbol, or more than one.
• PriceServerError — Error communicating with Pyth network.
• ProviderConnectionError — Error indicating a connection failure when submitting a transaction to the provider.
• ReadTimeoutError — Error thrown when an SDK read exceeds its whole-operation deadline.
• TransactionPopulationError — This error is thrown if there is an error populating a transaction.
• TransactionRevertError — Error indicating a transaction was reverted.
• UnsupportedSignatureTypeError — This error is thrown if a signature type is requested by name but not found.
• UserRejectedRequestError — Error indicating a user rejected a transaction request in the wallet or signer provider.
• ValidationError — Represents a user-input validation failure from the SDK.
• WalletNotConnectedError — This error is thrown if, based on configuration, the SDK expects the browser wallet to be unlocked, but it is not.
• WorkflowSignerChangedError — Thrown when a prepared workflow observes a different connected account than the account used to plan it.

Supporting types and functions in this group are not listed here; each has its own page, listed with the group in the sidebar.