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
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
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
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
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
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.
When setting multiple override messages, the one corresponding to the first failed predicate is used, starting from the innermost refinement to the outermost:
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.
Transformations
In this example, IntFromString is a transformation schema that converts strings to integers. It applies specific validation messages based on different scenarios.
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
Effectful messages
Messages are not only of type string but can return an Effect so that they can have dependencies (for example, from an internationalization service). Let’s see the outline of a similar situation with a very simplified example for demonstration purposes:
Example
Missing messages
You can provide custom messages for missing fields or elements using the missingMessage annotation.