Adding 'Type' to ResultError struct about gojsonschema HOT 4 CLOSED

There is definitely room for improvements with locales in error handling and it is something i have been "struggling" with when writing the library. The main difficulty is i guess to find a way to handle all errors, those that imply one field, those implying two fields etc... Which might result in dealing with different kinds of structures for each error type.

Also this is going to be some kind of archeology work for now :) Making sure all errors are taken in account ( schema creation ones + validation ones ).

I honestly dont know what is the best solution but here are some thoughts:

• We must keep the standard locales modes, forcing the library user to implements all kinds of errors before being able to use it is quite repulsive.
• Allowing the user to override the locales in a Printf fashion can be a good solution. ex : SetErrorLocale( Type, "%field Must be greater than %value" )
• We could provide interfaces and default implementations for all types of errors. So that the user can use the default ones or write/update his own versions. This may also allow them to write their own formatters, a good thing when dealing with JSON APIs for example.
• If there is a single way to represent all kinds of errors, i mean using the same structure, i guess the Type system works. If not, I am afraid the user will have to perform some big ugly switch to handle all types and output them accordingly.

from gojsonschema.

Thanks for the thoughts. There are definitely several different layers of accomplishing this.

The example I put together is the simplest I could think of: Add a new Type field to the struct and identify the error. Then each developer can work with that in their own library to implement their own responses (should they need to) like the example I gave above. The idea here is to just add more context to the ResultError, which is only used for validation - so I did not do anything with schema errors.

The locales currently can't be overwritten because they are constants... I left that as is.

The user also would not have implement anything to use and this would be backwards compatible. They would just receive an additional Type field on the errors with a string like "invalid_type", "enum", etc. If there are multiple errors, there would be multiple ResultError structs returned, and each of those would have the new Type field so it would still address that use case.

I'm curious to get your thoughts just given the limited scope. What I'm going for is something similar to #6 which just adds more context to the error without breaking BC.

As a more long-term solution, I think allowing library users to create a locale struct or map[string]string and pass that into the library... otherwise the default locale will be used. This would do away with the locale constants. Each error should contain error details that are specific to that error. For example: invalid type might contain details: { "expected": "string", "given": TYPE_BOOLEAN} which can then be converted into the string replacements %expected% and %given%. GTE might contain ErrorDetails{"min": 10}. The locales would then return a string like: "%field% must be a %expected%, %given% given" and the library will handle the replacements. Each error would be it's own type (i.e. InvalidTypeError and still have a type field for easy comparison).

addError would then be called like this:

result.addError(ErrorTypeInvalid, context, currentNode, ErrorDetails{"expected": currentSubSchema.types.String(), "given": TYPE_STRING})

which would return an error struct that looks like this:

InvalidTypeError {
    Type:       "invalid_type",
    Context:     *jsonContext,
    Description: "firstName should be a string, boolean given"
    Value:       value,
    Details:     ErrorDetails{
            "expected": "string"
            "given": "boolean"
        }
}

And as a string:

(root).firstName firstName should be a string, boolean given

Schema errors could be handled the same way, but the call to errors.New() would just be a string that is generated in the same way as validation errors.

from gojsonschema.

I'm actually working through a prototype of the second-half of my last comment. I'll just submit as a PR in the next day or two to get your thoughts.

from gojsonschema.

Just realized I didn't link to this discussion in my PR. Here's the link the PR: #52

from gojsonschema.