Skip to main content

Overview

core-ai provides a hierarchy of error types that help you handle failures gracefully. For the complete API surface, see the errors reference.

Error Hierarchy

CoreAIError

Base error class for all core-ai errors.
Usage:
Check for the most specific error types first, then fall back to CoreAIError to catch any standardized library error.

ValidationError

Thrown when core-ai rejects invalid caller input or local request configuration before making a provider call.
When thrown:
  • Empty messages array
  • Empty input for embeddings
  • Empty prompt for image generation
  • Unsupported input modalities in user messages (UnsupportedInputModalityError)
  • Unsupported, excessive, or non-strict-capable strict tool schemas (ToolSchemaStrictnessError)
  • Tool parameters or a structured output schema that cannot be converted to JSON Schema, including a Standard Schema without JSON Schema support
  • A request that breaks a tool discovery rule, such as an unanswered discovery call
  • Invalid local request configuration
core-ai does not check the tool call arguments a model returns. validateToolCall() checks them against a tool’s Standard Schema and reports problems as issues instead of throwing. See Validate tool calls. ToolSchemaStrictnessError includes typed providerId, modelId, toolNames, reason, and optional maxStrictTools, maxUnionParameters, unionParameterCount, and violations fields. Its reason is one of 'unsupported', 'limit-exceeded', 'union-limit-exceeded', or 'invalid-schema'. Core-ai throws it before the provider request. See the errors reference for the complete shape.

AbortedError

Thrown when an operation is cancelled via an AbortSignal.

StreamAbortedError

Thrown when a streaming operation is aborted via an AbortSignal.
Usage:
StreamAbortedError applies to an in-flight stream. Validation errors such as empty messages throw ValidationError.

ProviderError

Error for provider API failures (network errors, API errors, rate limits, etc.). Discriminate with subclasses and instanceof. Transient failures (RateLimitError, ModelOverloadedError, ServiceUnavailableError) extend RetryableProviderError so you can retry with a single check.
Each provider wrap*Error helper decides which subclass to throw from SDK-specific fields (error types, status codes, message shapes). Typical order inside a wrapper: abort → context length → media / image count → provider specials (quota, Azure capacity) → overload → rate limit → service unavailable / transient 5xx → generic ProviderError. HTTP 429 is not always RateLimitError. For example OpenAI insufficient_quota stays a non-retryable ProviderError, while Azure NoCapacity maps to ModelOverloadedError. Provider-specific quirks stay in the provider package (Azure "Backend error." as unavailable, Vertex RESOURCE_EXHAUSTED as a rate limit). Usage:
Subclass details:
  • ContextLengthExceededError — optional maxTokens / actualTokens when token counts are parseable (string-length limits are classified without inventing token metadata)
  • MediaCountExceededError — base class for media-count limits, thrown directly when images and document pages share one limit; optional maxMedia / actualMedia when the provider reports them. Not retryable until images or documents are removed from the messages.
  • ImageCountExceededError — subclass of MediaCountExceededError for a limit on images alone; maxMedia / actualMedia count images. Not retryable until images are removed from the messages. The counts are the provider’s own and can include inputs other than image parts, such as document pages. Check your messages for image parts before you ask a user to remove images.
  • RateLimitError — optional retryAfterSeconds from Retry-After, Azure retry-after-ms, or an HTTP-date Retry-After value
  • ModelOverloadedError — capacity / high-demand signal (wins over generic 5xx unavailable; Azure NoCapacity on 429 included)
  • ServiceUnavailableError — temporary unavailability, including HTTP 500/502/503/504
Catch ImageCountExceededError first to ask for fewer images, then MediaCountExceededError for the general case. The errors cover the wordings each provider is known to return:
  • OpenAI-based providers — the two Azure OpenAI wordings. Every OpenAI-based provider matches them, but other backends may word the limit differently.
  • Anthropic and Anthropic Vertex — MediaCountExceededError for both media-limit wordings of the Anthropic API. Anthropic Vertex matches them, but Vertex may word the limit differently.
  • Gemini API and Vertex Gemini — the Gemini API wording. Vertex Gemini matches it, but Vertex may word the limit differently.
  • Mistral — the Mistral API wording.
Any other wording stays a generic ProviderError, so keep a ProviderError branch as the fallback.

Structured Output Errors

Errors specific to structured output generation (generateObject and streamObject).

StructuredOutputError

Base class for all structured output errors.
Properties:
  • rawOutput: The raw text output from the model (if available)
  • provider: Which provider was used
  • statusCode: HTTP status code (if applicable)
  • cause: Underlying error that caused this error

StructuredOutputNoObjectGeneratedError

Thrown when the model doesn’t generate any structured output.
When thrown:
  • Model responds with regular text instead of structured output
  • Tool call for structured output was not made
  • Finish reason is not ‘stop’ or ‘tool-calls’

StructuredOutputParseError

Thrown when the model’s output cannot be parsed as JSON.
When thrown:
  • Model output is not valid JSON
  • JSON syntax errors in model output
  • Malformed structured output

StructuredOutputValidationError

Thrown when the model’s output doesn’t match a Standard Schema. core-ai never validates output against plain JSON Schema, so it never raises this error for one.
Properties:
  • issues: Validation messages from the schema library, each formatted as path.to.key: message (<root> for issues at the root)
When thrown:
  • Missing required fields
  • Wrong data types
  • Values that don’t match schema constraints
  • Invalid enum values

Complete Error Handling Example

Retry Strategies

Exponential Backoff

Circuit Breaker

Validation Best Practices

Validate inputs before sending: Check for empty messages, validate file sizes, and ensure proper content types before making API calls to avoid unnecessary errors.

Logging Errors

Log error details for debugging: Include provider, model, status codes, and raw output when available to help diagnose issues.

Next Steps

  • Learn about Providers for provider-specific behavior
  • Explore Configuration for controlling generation
  • Understand Messages for building conversations