Make all errors raised fully distinguishable from other errors by machine

[odscjames]

Hi, and thanks for this library.

We have some difficulties using it, and have a suggestion.

When a problem is found, this library raises a ValidationError with a human readable message.

Human readable messages are great for quick display and shouldn't be removed, but it's also important to be able to fully see what kind of error it was in code too. You may be:

• Writing something that is looking for specific errors.
• Reporting on types of errors en-mass over lots of data.
• Wanting to change how the error is presented to the user, to make it more relevant or easy to understand with regards to the specific situation
• Translate the error to another language.

(We have done or have wanted to do all these things)

The error object has variables like validator and validator_value that may give you some help here, but not always. Sometimes you need to start parsing the actual text of the message to see what error you are looking at. Parsing the message isn't ideal as:

• This is fragile, as the text could change at some point
• Is harder to write and test, making sure all cases are dealt with

What do you think about some work to add more information to errors, such that we have the principle: Make all errors raised fully distinguishable from other errors by machine

("By Machine" isn't great wording but right now I can't think of a better one. I basically mean as opposed to "by a human")

There are different ways this could be done, and we can discuss that later, but the main thing to say now is there are several that would be fully backwards-compatible.

Here's an example where a validator can return 2 different errors, and only analysing the message would tell you which one was being returned:
https://github.com/Julian/jsonschema/blob/main/jsonschema/_validators.py#L346-L367

We can get involved more later if wanted - first we just wanted to check if you think this is something interesting to work on?

[Julian]

Hi there.

The specific lines in that link have been lost (because it's a link to the moving branch) -- would be curious to see which one you point out.

In short though, as far as I know, this should already be the case, other than #119 for which a patch is still welcome.

But certainly this principle is explicitly a goal of this library, and parsing human readable messages are explicitly not part of the public API

So definitely any further examples are welcome and PRs to fix them would be accepted.