Error Handling

Recommended pattern

import {
  DumpsterError,
  DumpsterErrorCode,
} from '@dumpster-cash/dumpster-sdk';

try {
  // fetch, build, or submit
} catch (error) {
  const dumpsterError = DumpsterError.fromAnchorError(error);

  switch (dumpsterError.code) {
    case DumpsterErrorCode.AccountNotFound:
      console.log('The target account does not exist on-chain.');
      break;
    case DumpsterErrorCode.BondingCurveComplete:
      console.log('Stop curve trading and refresh migration/pool evidence.');
      break;
    case DumpsterErrorCode.BondingCurveAlreadySettled:
      console.log('Do not repeat settlement; refresh canonical-pool evidence.');
      break;
    case DumpsterErrorCode.CreatorMismatch:
      console.log('Creator records disagree; request designated-authority review.');
      break;
    case DumpsterErrorCode.SlippageExceeded:
      console.log('Refresh the preview and rebuild the transaction.');
      break;
    case DumpsterErrorCode.MigrationDisabled:
      console.log('Migration is currently unavailable for this token.');
      break;
    default:
      throw dumpsterError;
  }
}

Useful codes

Fetch/setup failures vs submitted-transaction failures

The SDK maps InsufficientMigrationLiquidityError (6025), CreatorMismatchError (6024), BondingCurveAlreadySettledError (6023) and InsufficientCurveLiquidityError (6022). Swap error NotCanonicalPool (6018) means the pool is not canonical for the configured migration program.

InsufficientMigrationLiquidity describes a migration funding rejection, not a wallet balance error or every possible migration failure. Rent, account-validation and downstream errors remain distinct.

create and set_params use the same configuration checks: invalid parameters return InvalidParams (6011), while checked-arithmetic failures return MathOverflow (6006). Inspect the failed instruction and logs before attributing the cause: create also uses InvalidParams for metadata lengths, and account, pause or authorization checks can fail first. Invalid stored settings need an authorized configuration update; changing a buyer's slippage does not correct them.

The normalizer recognizes the SDK's custom error classes; it does not decode every raw Anchor/RPC error shape. Preserve the original cause and treat unrecognized failures as Unknown. Do not turn CreatorMismatch into an automatic repair or retry with a guessed recipient.

• fetch/setup failures usually become AccountNotFound, TransactionBuildFailed, or Unknown
• submitted transactions often become SlippageExceeded, Disabled, InsufficientBalance, or MigrationDisabled

Branch only on recognized codes. An Unknown result is not evidence that an account is absent or an operation succeeded.

Recipient configuration and selection

Recipient checks use the errors below.

Swap 6020's message is Fee recipients must include at least one non-zero address, sorted and unique, with empty slots last. Earlier account/runtime checks can fail before recipient membership, and these codes also have other uses; inspect the failed instruction and logs rather than assuming every rejection has the same cause.

Curve selection throws the plain setup error No fee recipients configured when neither an optional entry nor the primary is active. Swap selection already throws No protocol fee recipients configured for an empty active set. These are not submitted-transaction errors: the existing normalizer reports them as Unknown while retaining their message and cause. Refresh configuration and report the missing setup; do not substitute an arbitrary wallet or treat it as a slippage retry. Raw configuration reads remain available. See fee helpers.

Match a single code directly

import {
  DumpsterErrorCode,
  matchesDumpsterErrorCode,
} from '@dumpster-cash/dumpster-sdk';

try {
  // submit transaction
} catch (error) {
  if (matchesDumpsterErrorCode(error, DumpsterErrorCode.SlippageExceeded)) {
    console.log('Ask the user to refresh the quote.');
  }
}