You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It might make sense to keep track of both the path within the document i.e. #.users[2].name as well as the path within the schema that it is getting validated against, and then communicate both of these when errors are encountered.
In a complex schema for example, you might have a schema which makes use of composition to reduce code duplication within the schema, which means that very deeply nested and branching schemas might result in dumb "validation failed" errors, which don't help in narrowing down the issue.
As an example, I was just trying to write a common sense example using password validation, where a schema like this one:
The schema would fail on karen, since her password does not contain any numbers, but the error produced does nothing to communicate this:
#[2].password: special requirements for field not met: supplied value does not match regex pattern for field
A better error message might be something along the lines of
#[2].password: special requirements for field not met: supplied value does not match regex pattern for field ($user-list.array.object.password.$must-contain-letter-and-number.allOf[1].$must-contain-number.string.pattern)
Although very verbose, it gives a clear idea of exactly which requirement failed.
Might be edge cases that are hard to name, such as in inversion of "not", or "oneOf" where validating multiple branches successfully is actually an error.
The text was updated successfully, but these errors were encountered:
It might make sense to keep track of both the
path
within the document i.e.#.users[2].name
as well as the path within the schema that it is getting validated against, and then communicate both of these when errors are encountered.In a complex schema for example, you might have a schema which makes use of composition to reduce code duplication within the schema, which means that very deeply nested and branching schemas might result in dumb "validation failed" errors, which don't help in narrowing down the issue.
As an example, I was just trying to write a common sense example using password validation, where a schema like this one:
... Would be used to validate this file:
The schema would fail on
karen
, since her password does not contain any numbers, but the error produced does nothing to communicate this:A better error message might be something along the lines of
Although very verbose, it gives a clear idea of exactly which requirement failed.
Might be edge cases that are hard to name, such as in inversion of "not", or "oneOf" where validating multiple branches successfully is actually an error.
The text was updated successfully, but these errors were encountered: