By default, when a parsing error occurs, the system automatically generates an informative message based on the schema’s structure and the nature of the error (see TreeFormatter for more informations).
For example, if a required property is missing or a data type does not match, the error message will clearly state the expectation versus the actual input.
Example (Type Mismatch)
Example (Missing Properties)
Example (Incorrect Property Type)
Enhancing Clarity in Error Messages with Identifiers
In scenarios where a schema has multiple fields or nested structures, the default error messages can become overly complex and verbose.
To address this, you can enhance the clarity and brevity of these messages by utilizing annotations such as identifier, title, and description.
Example (Using Identifiers for Clarity)
Refinements
When a refinement fails, the default error message indicates whether the failure occurred in the “from” part or within the predicate defining the refinement:
Example (Refinement Errors)
In the first example, the error message indicates a “from side” refinement failure in the name property, specifying that a string was expected but received null.
In the second example, a “predicate” refinement failure is reported, indicating that a non-empty string was expected for name but an empty string was provided.
Transformations
Transformations between different types or formats can occasionally result in errors.
The system provides a structured error message to specify where the error occurred:
Encoded Side Failure: Errors on this side typically indicate that the input to the transformation does not match the expected initial type or format. For example, receiving a null when a string is expected.
Transformation Process Failure: This type of error arises when the transformation logic itself fails, such as when the input does not meet the criteria specified within the transformation functions.
Type Side Failure: Occurs when the output of a transformation does not meet the schema requirements on the decoded side. This can happen if the transformed value fails subsequent validations or conditions.
Example (Transformation Errors)
Custom Error Messages
You have the capability to define custom error messages specifically tailored for different parts of your schema using the message annotation.
This allows developers to provide more context-specific feedback which can improve the debugging and validation processes.
Here’s an overview of the MessageAnnotation type, which you can use to craft these messages:
Return Type
Description
string
Provides a static message that directly describes the error.
Effect<string>
Utilizes dynamic messages that can incorporate results from synchronous processes or rely on optional dependencies.
Object (with message and override)
Allows you to define a specific error message along with a boolean flag (override). This flag determines if the custom message should supersede any default or nested custom messages, providing precise control over the error output displayed to users.
Example (Custom Error Message for a String Schema)
General Guidelines for Messages
The general logic followed to determine the messages is as follows:
If no custom messages are set, the default message related to the innermost schema where the operation (i.e., decoding or encoding) failed is used.
If custom messages are set, then the message corresponding to the first failed schema is used, starting from the innermost schema to the outermost. However, if the failing schema does not have a custom message, then the default message is used.
As an opt-in feature, you can override guideline 2 by setting the overwrite flag to true. This allows the custom message to take precedence over all other custom messages from inner schemas. This is to address the scenario where a user wants to define a single cumulative custom message describing the properties that a valid value must have and does not want to see default messages.
Let’s see some practical examples.
Scalar Schemas
Example (Simple Custom Message for Scalar Schema)
Refinements
This example demonstrates setting a custom message on the last refinement in a chain of refinements. As you can see, the custom message is only used if the refinement related to maxLength fails; otherwise, default messages are used.
Example (Custom Message on Last Refinement in Chain)
When setting multiple custom messages, the one corresponding to the first failed predicate is used, starting from the innermost refinement to the outermost:
Example (Custom Messages for Multiple Refinements)
You have the option to change the default behavior by setting the override flag to true. This is useful when you want to create a single comprehensive custom message that describes the required properties of a valid value without displaying default messages.
Example (Overriding Default Messages)
Transformations
In this example, IntFromString is a transformation schema that converts strings to integers. It applies specific validation messages based on different scenarios.
Example (Custom Error Messages for String-to-Integer Transformation)
Compound Schemas
The custom message system becomes especially handy when dealing with complex schemas, unlike simple scalar values like string or number. For instance, consider a schema comprising nested structures, such as a struct containing an array of other structs. Let’s explore an example demonstrating the advantage of default messages in handling decoding errors within such nested structures:
Example (Custom Error Messages in Nested Schemas)
Effectful messages
Error messages can go beyond simple strings by returning an Effect, allowing them to access dependencies, such as an internationalization service. This approach lets messages dynamically adjust based on external context or services. Below is an example illustrating how to create effect-based messages.
Example (Effect-Based Message with Internationalization Service)
Missing messages
You can provide custom messages for missing fields or tuple elements using the missingMessage annotation.
Example (Custom Message for Missing Property)
In this example, a custom message is defined for a missing name property in the Person schema.
Example (Custom Message for Missing Tuple Elements)
Here, each element in the Point tuple schema has a specific custom message if the element is missing.