Background:

In regulatory environments, it is important to be mindful of the information that is logged and returned to users, as it may contain sensitive information such as private details, payment information, or secrets.

When a SchemaError occurs, the default error message produced by the Error() method includes the Value field. While it is possible to customize the error message using the WithCustomSchemaErrorFunc function, this requires the user to manually handle each possible schema validation error to produce a meaningful message.

Suggested Solution:

I suggest making the SchemaError.Reason field "safe" by guaranteeing that it will not contain the original Value. This will allow users to simply return SchemaError.Reason in their custom error function, rather than having to craft the entire message for each possible scenario.

Upon review, most messages in the Reason field are already "safe" and do not include the original Value. However, there are a few messages that should be revised to remove the Value:

"value \"%g\" must be an integer" => "value must be an integer"
`string %q doesn't match the regular expression "%s"` => `string doesn't match the regular expression %q`
"value %q is not one of the allowed values" => "value must be one of the allowed values %v"
"value of discriminator property %q is not a string: %v" => "value of discriminator property %q is not a string"
"discriminator property %q has invalid value: %q" => "discriminator property %q has invalid value"