Skip to main content

Exception Handling

Overview​

Exception handling is a critical part of any application. This document outlines the structure of exception objects returned by our API. Our logging mechanisms are designed to be RFC 9457 compliant, ensuring consistent and comprehensive logging across different parts of our system. This approach facilitates better monitoring, debugging, and compliance with regulatory requirements when issues arise.

Exception Object Fields​

According to RFC 9457, the Problem Details JSON object must include the following fields:

  • type: A URI reference that identifies the problem type. This member is mandatory and provides a machine-readable identifier for the error.
  • title: A short, human-readable summary of the problem type. It should remain consistent across occurrences of the problem except for localization purposes.
  • status: The HTTP status code generated by the origin server for this occurrence of the problem. It is a numeric value and is included for the convenience of the client.
  • detail: A human-readable explanation specific to this occurrence of the problem. This field helps the client understand and potentially correct the issue.
  • instance: A URI reference that identifies the specific occurrence of the problem. This provides a unique identifier for the particular instance of the error.
  • timestamp: A string recording the exact date and time when the exception occurred, in the ISO8601 format (YYYY-MM-DDTHH:mm:ss.sssZ). This timestamp is crucial for tracking the occurrence of errors and facilitating debugging processes.
  • values: An optional field that contains a map of key-value pairs, providing additional context or data relevant to the error.

Extension Members​

The Problem Details object can be extended with additional fields specific to the application's needs. These fields should be carefully named and documented in each exception.

For more detailed information on the Problem Details specification, refer to RFC 9457.

Exception List​

Required Key ID​

This exception occurs when a key ID is required but not provided in the request.

Required Payload to Sign​

This exception occurs when the payload to sign is missing for a given key ID and round.

No DKG Round Found​

This exception occurs when the server cannot find the DKG round state for a specified key ID.

Invalid DKG Round​

This exception occurs when the key is not ready for the expected round, indicating a mismatch between the expected and actual round numbers.

No Key Found​

This exception occurs when the server cannot find a key with the specified key ID.

Frost Request JSON Invalid​

This exception occurs when the JSON payload of a Frost request is invalid.

Invalid Key ID​

This exception is thrown when an invalid key ID is provided. It occurs when attempting to generate a client share while a server share already exists.

Doerner18 Error​

This exception occurs when there is an internal error related to the Doerner18 protocol.

ECDSA Signature Failed​

This exception occurs when an ECDSA signature operation fails during the server round.

Handler Channel Panic​

This exception occurs when the handler channel panics during a request.

DKG State Expired​

This exception occurs when a DKG state has expired and is being removed.

Network Error​

This exception occurs during network requests, indicating that the network action failed.

Unhandled Error​

This is a generic exception for errors that are not specifically handled.