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 requests

Complete 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