Overview
The NEAR API TypeScript library uses a sophisticated error handling system calledNatError. It provides strongly-typed, structured errors with full context, enabling precise error handling and debugging.
The NatError System
NatError Class
NatError has two key properties:
- kind: A string identifier for the error type (e.g.,
'Client.GetAccountInfo.Rpc.Account.NotFound') - context: Typed contextual data specific to the error kind
Error Hierarchy
Errors are organized in a hierarchical namespace:Client.GetAccountInfo.Rpc.Account.NotFoundMemorySigner.ExecuteTransaction.KeyPool.SigningKey.NotFoundCreateMemoryKeyService.Args.InvalidSchemaMemoryKeyService.SignTransaction.Internal
Error Registries
Each component defines its error registry using TypeScript interfaces:- Error kinds: All possible error strings
- Context types: What data each error includes
- Type safety: Compiler ensures correct error handling
Safe vs Throwable Variants
Every operation in the library comes in two flavors:Throwable Variants
Traditional functions that throw errors:Safe Variants
Return aResult<T, E> type for explicit error handling:
Result Type
TheResult type represents either success or failure:
Working with Results
Error Categories
Schema Validation Errors
These occur when arguments don’t match the expected schema:RPC Errors
Errors from the NEAR RPC endpoint:- Account Not Found
- Block Not Found
- Access Key Not Found
Transaction Errors
Errors during transaction execution:- Receiver Not Found
- Insufficient Balance
- Account Already Exists
Key Service Errors
Errors from key management operations:Signer Errors
Errors from the signing process:- Key Pool Empty
- Signing Key Not Found
- Task Queue Timeout
Internal Errors
Unexpected errors that indicate bugs or system issues:Error Checking Utilities
isNatError
Check if an error is aNatError:
isNatError with Kind
Check for a specific error kind:isNatErrorOf
Check if error matches any of multiple kinds:Error Handling Patterns
Pattern 1: Exhaustive Error Handling
Handle all known error types explicitly:Pattern 2: Category-Based Handling
Group errors by category:Pattern 3: Early Return Pattern
Return early on errors for cleaner code:Pattern 4: Error Recovery
Attempt recovery based on error type:Complete Error Registry
Full Error Registry (Collapsed for Brevity)
Full Error Registry (Collapsed for Brevity)
The library defines a comprehensive error registry covering all components:
Best Practices
Always Use Safe Variants in Production
Use safe variants (
safeExecuteTransaction, safeGetAccountInfo) for explicit error handling. Reserve throwable variants for prototyping and testing.Handle Expected Errors Explicitly
For business-critical operations, handle all expected error types explicitly with switch statements.
Log Internal Errors
Always log internal errors with full context. These indicate bugs or system issues that need investigation.
Provide User-Friendly Messages
Convert error kinds into user-friendly messages:
Don't Swallow Errors
Never catch errors without handling or logging them. Use safe variants to make error handling explicit.
Related Concepts
- Clients - Client error types
- Key Services - KeyService error types
- Signers - Signer error types
- Transactions - Transaction error types