Error Handling and Validation
Building Robust Handlers with Comprehensive Error Management
← Back to Understanding XRPL(d) RPC Architecture
Introduction
The difference between a fragile handler and a production-ready one lies in proper error handling and input validation. Every RPC handler must anticipate failures—invalid input, missing resources, permission issues, and unexpected edge cases—and respond with clear, actionable error messages.
In this section, you'll learn the complete error handling framework used throughout Rippled, including standard error codes, HTTP status mapping, input validation patterns, and strategies for protecting sensitive data while providing useful debugging information.
RPC Error Codes
Rippled defines a comprehensive set of error codes for different failure scenarios:
Standard Error Codes
Source Location: src/xrpl/protocol/ErrorCodes.h
// Parameter validation errors
rpcINVALID_PARAMS // Invalid or missing parameters
rpcBAD_SYNTAX // Malformed request structure
rpcINVALID_API_VERSION // Requested API version not supported
// Authentication/Permission errors
rpcNO_PERMISSION // Insufficient role for operation
rpcFORBIDDEN // Client IP blacklisted
rpcBAD_AUTH_MASTER // Master key authentication failed
rpcBAD_AUTH_TOKEN // Token authentication failed
// Ledger-related errors
rpcNO_CURRENT // No current (open) ledger available
rpcNO_CLOSED // No closed (validated) ledger available
rpcLGR_NOT_FOUND // Specified ledger not found
rpcLGR_IDXS_NOTFND // Ledger indices not found
rpcLGR_INDEX_BOUNDS // Ledger index out of valid range
// Account-related errors
rpcACT_NOT_FOUND // Account not found in ledger
rpcACT_MALFORMED // Account address malformed
rpcDUPLICATE // Duplicate account in request
// Transaction-related errors
rpcTXN_NOT_FOUND // Transaction not found
rpcTXN_FAILED // Transaction validation failed
rpcMASTER_DISABLED // Master key disabled on account
rpcINSUFFICIENT_FUNDS // Insufficient funds for operation
// Network/Server errors
rpcNO_NETWORK // Node not connected to network
rpcCOMMAND_UNIMPLEMENTED // Command not implemented
rpcUNKNOWN_COMMAND // Unknown RPC command
rpcINTERNAL // Internal server error
rpcSLOW_DOWN // Rate limited - too many requestsComplete Error Code List
For a comprehensive list of all error codes and their meanings:
HTTP Status Code Mapping
RPC errors must map to appropriate HTTP status codes:
Mapping Strategy
Example HTTP Response
Error Response Formatting
Standard Error Response Structure
Every error response follows this format:
Building Error Responses in Code
Source Location: src/xrpld/rpc/detail/RPCHelpers.h
Input Validation Patterns
Validate Required Fields
Validate Numeric Ranges
Validate Addresses and Identifiers
Validate Enum/Choice Parameters
Validate Optional Fields
Sensitive Data Masking
Protect Private Keys and Secrets
Sanitize Error Messages
Mask Sensitive Request Data
Exception Handling
Catch Exceptions in Handlers
Standard Exception Types
Comprehensive Validation Example
Here's a complete example showing all validation patterns:
Validation Best Practices
✅ DO
Validate early and often — Check all inputs before processing
Use specific error messages — Help clients understand what went wrong
Validate all numeric bounds — Prevent overflow, underflow, and resource exhaustion
Check account existence — Before attempting operations
Log validation failures — For security monitoring and debugging
Fail fast — Return errors as soon as validation fails
❌ DON'T
Trust client input — Always validate, even if it looks correct
Expose internal errors — Sanitize error messages
Allow injection attacks — Escape or validate all string inputs
Leak sensitive data — Never include secrets in responses
Ignore format validation — Invalid formats can cause crashes
Disable validation for "trusted" clients — All clients need validation
Common Validation Scenarios
Scenario 1: Currency/Amount Handling
Scenario 2: Ledger Index Selection
Scenario 3: Pagination Validation
Conclusion
Comprehensive error handling and input validation separate production-quality handlers from fragile prototypes. Rippled's error framework provides specific codes for every failure scenario, proper HTTP status mapping, and patterns for protecting sensitive information while giving clients actionable feedback. By validating inputs early, handling exceptions gracefully, and following the principle of failing fast, handlers become robust against malformed requests, edge cases, and potential attacks. These practices are fundamental for any handler that will face real-world traffic.
Last updated

