Is there a way to use the errorMessage from the schema when validation fails? #573
-
Hello, I am currently using JSONCONS in C++ for validating JSON against a schema. I was wondering if there's a way to extract the 'errorMessage' directly when a JSON schema validation fails. In my use case, I have a JSON schema with specific validation rules and I want to provide informative error messages to the end users when their JSON fails to validate against the schema. I noticed that there are 'errorMessage' annotations in the JSON schema draft-07, which allow for custom error messages. My question is, does JSONCONS support these 'errorMessage' annotations and if so, how can I extract these custom error messages when a validation error occurs? Any guidance on this would be greatly appreciated. Thank you. |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 3 replies
-
|
Beta Was this translation helpful? Give feedback.
-
I've added support for an The
An example of an object that maps message keys to custom messages is {
"maxItems" : "At most 3 numbers are allowed in 'foo'",
"type" : "Only numbers are allowed in 'foo'",
"format.date": "Date format must be YYYY-MM-DD"
} Maps are visible in the lexical scope of a schema. Message keys are JSON Schema keywords, except for
This implementation of key-message maps draws on the experience of networknt json-schema-validator. We do not currently support parameterized messages. Example#include <jsoncons/json.hpp>
#include <jsoncons_ext/jsonschema/jsonschema.hpp>
#include <iostream>
namespace jsonschema = jsoncons::jsonschema;
int main()
{
std::string schema_str = R"(
{
"type": "object",
"properties": {
"date": {
"type": "string",
"format": "date"
},
"foo": {
"type": "array",
"maxItems": 3,
"items" : {
"type" : "number"
},
"errorMessage" : {
"maxItems" : "At most 3 numbers are allowed in 'foo'",
"type" : "Only numbers are allowed in 'foo'"
}
},
"bar": {
"type": "string",
"errorMessage" : "Type of `bar` must be string"
}
},
"errorMessage": {
"format.date": "Date format must be YYYY-MM-DD"
}
}
)";
auto options = jsonschema::evaluation_options{}
.enable_custom_error_message(true)
.require_format_validation(true);
auto schema = jsoncons::json::parse(schema_str);
auto compiled = jsonschema::make_json_schema<jsoncons::json>(schema, options);
std::string data_str = R"(
{
"foo": [1, 2, "three"],
"bar": 123,
"date": "05-13-1955"
}
)";
auto data = jsoncons::json::parse(data_str);
std::vector<std::string> messages;
auto reporter = [&](const jsonschema::validation_message& msg) -> jsonschema::walk_result
{
messages.push_back(msg.message());
return jsonschema::walk_result::advance;
};
compiled.validate(data, reporter);
for (const auto& msg : messages)
{
std::cout << msg << "\n";
}
} Output:
|
Beta Was this translation helpful? Give feedback.
-
You can nest errorMessage members in allOf and oneOf schemas, e.g. #include <jsoncons/json.hpp>
#include <jsoncons_ext/jsonschema/jsonschema.hpp>
#include <iostream>
using namespace jsoncons;
namespace jsonschema = jsoncons::jsonschema;
std::string schema_str = R"(
{
"$id" : "https://www.example.com/main",
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "http://localhost:1234/draft2020-12/object",
"type": "object",
"properties": {
"name": {"anyOf" : [
{"type" : "string", "errorMessage": {"type" : "NOT a string!!!"}},
{"type" : "boolean", "errorMessage": {"type" : "NOT a boolean!!!"}}
]}
}
}
)";
int main()
{
try
{
json schema = json::parse(schema_str);
// Data
json data = json::parse(R"(
{
"name": {
"name": null
}
}
)");
// Throws schema_error if JSON Schema compilation fails
auto options = jsonschema::evaluation_options{}
.enable_custom_error_message(true);
jsonschema::json_schema<json> compiled = jsonschema::make_json_schema(schema, options);
json_decoder<json> decoder;
compiled.validate(data, decoder);
auto result = decoder.get_result();
std::cout << pretty_print(result) << "\n";
}
catch (const std::exception& e)
{
std::cout << e.what() << '\n';
}
} Output:
|
Beta Was this translation helpful? Give feedback.
Apologies, I misunderstood the question. No, we currently don't keep the 'errorMessage' property, but we'll look into adding that in the next release.