Machine readable validation errors

[jankuca]

Currently, there is the exception.code info available on certain validation errors but not nearly all errors can be processed without parsing the human-readable error message.

I would like to process validation errors and for instance present various error-specific responses from my API and the best I can do now without parsing the message is to separate 404 and 400 errors.

Proposal: I'm proposing adding new metadata to the exceptions which would precisely describe the validation issue. Results in a format similar to the following would be nice:

exception.code = 'BAD_PARAMS'
exception.params: Array<{
  code: 'missing' | 'invalid' | 'duplicate',
  location: 'path' | 'query' | 'header',
  key: string,
  value: unknown,
}>

Example: For a query parameter not matching a specified string pattern, the result.error.params info would contain an item such as { code: 'invalid', location: 'query', key: 'email', value: 'the invalid value' }.

What are your thoughts on this?

[Gi60s]

Hello @jankuca and sorry for the slow response.

I really like your idea. I will need to look into how this plays with the nested nature of the exceptions. Currently, there is a tree of exception nodes that work together to build the human-readable output.

To produce the computer-readable output you may need to traverse the tree and pull out the data from each exception node individually. There could be a way to facilitate that too, but I'm going to have to think about this a bit more.

Can you give me an example of how you might use the computer-readable exception output? That could help me to better understand how this new data would be useful.

[Gi60s]

Just an update. This is proving to be more complex than anticipated, but I wanted to let you know that it is not forgotten.

[Gi60s]

Another update: this will be available in version 2 of the library.