Skip to main content
The ACP TypeScript SDK follows JSON-RPC 2.0 error conventions, providing structured error handling for all requests and responses.

RequestError Class

The RequestError class represents JSON-RPC errors that can be thrown from request handlers:

Properties

  • code: Numeric error code (see Error Codes below)
  • message: Human-readable error description
  • data: Optional additional error information
RequestError extends the standard JavaScript Error class, so it can be caught and thrown like any other error.

Error Codes

The SDK provides static factory methods for standard JSON-RPC error codes:

Parse Error (-32700)

Invalid JSON was received:
Signature:

Invalid Request (-32600)

The JSON is valid but not a proper request object:
Signature:

Method Not Found (-32601)

The requested method doesn’t exist or isn’t available:
Signature:
Always throw methodNotFound for unknown methods in your extMethod handlers to maintain protocol compliance.

Invalid Params (-32602)

The method parameters are invalid:
Signature:

Internal Error (-32603)

An internal server error occurred:
Signature:

Custom ACP Errors

The SDK also includes ACP-specific error codes:

Authentication Required (-32000)

Signature:

Resource Not Found (-32002)

Signature:

Throwing Errors

Throw RequestError from any request handler to send a structured error response:

Catching Errors

When calling methods on the connection, catch errors to handle failures:
When a request fails, the promise is rejected with the JSON-RPC ErrorResponse object, not a RequestError instance.

Error Response Type

The error response follows the JSON-RPC 2.0 specification:

Automatic Error Handling

The SDK automatically handles certain errors:

Zod Validation Errors

If a request handler receives invalid parameters, the SDK catches Zod validation errors and converts them to invalidParams errors:

Unexpected Errors

If an unexpected error is thrown from a request handler, the SDK converts it to an internalError:

Best Practices

Do:
  • Use the appropriate error code for each error type
  • Include helpful error messages
  • Add structured data for debugging
  • Throw methodNotFound for unknown extension methods
Don’t:
  • Throw generic Error objects (use RequestError instead)
  • Include sensitive data in error messages
  • Swallow errors without handling them
  • Use error codes outside the JSON-RPC specification

Custom Error Codes

For application-specific errors, use custom error codes in the range -32000 to -32099 (reserved for implementation-defined errors):

Error Handling Example

Complete example showing comprehensive error handling: