unique identifier for validation errors

[sigmonsays]

Would it be possible to specify a list of unique integer ids for the type of validation that failed?

This would atleast allow the caller to write code to uniquely handled specific conditions

For instance

	err := message.Validate()
	verr := err.(*validator.Error)
	if verr.Code == 5 {
		fmt.Printf("this is a fatal error")
	} else {
		fmt.Printf("this is a temporary error")
	}

[c4milo]

I'm all for this too. This will allow to map the errors to app specific errors which may include more context.

[mwitkow]

Would you mean an error per: field, field-validator, or a declarative code (you provide which code failed)?

If you need this now, can you use the human_error as a hint to differentiate the field-level error in the mean time?

[adam-26]

Could the Validate() method return a struct instead of a string? If it included all the validation data (failed rule type, invalid value(s), default error message - used for the error interface) it would allow callers to handle specific errors.

It would also allow callers to localize error messages, this would be a great feature.

It could even allow multiple errors per field to be returned, so that callers understand every rule an invalid value is violating.

[sigmonsays]

I would think it could just be a new field (like msg_exists or int_gt) which is treated as a integer value. The meaning being entirely arbitrary just that it could be returned as a concrete type from an error interface.

To elaborate on the example I previously provided I imagine a proto message like this

message Request {
 int32 Age = 1 [(validator.field) = { int_gt : 0, int_gt : 150, error_code = 1 }
}

Then you would have a type which encapsulates that error code, like

type Error struct {
 ErrorCode int 
 Message string
}

which u could then do verr := err.(*validator.Error) on and access error_code (value 1) from verr.ErrorCode

[mwitkow]

Ok, this is interesting: I was toying with the idea of extending the Error struct, however I was considering adding access to the field.

@sigmonsays : what is the actual use case you have? If you had access to the field affected, wouldn't that address your error_code use case?

@adam-26:

"It could even allow multiple errors per field to be returned, so that callers understand every rule an invalid value is violating."

Are you proposing to return all failed rules instead of the first one that fails? If so, please file this as a separate ticket, it definitely makes sense and is independent of this discussion.

If it included all the validation data (failed rule type, invalid value(s), default error message - used for the error interface) it would allow callers to handle specific errors.
Ok so, it seems that in order to localize your error (which I assume is what you want), you'd need:

• the name (or field id) of the FieldValidator that triggered the error
• the struct-path to the Field that failed (e.g. for nested nested messages)
• the original error message
• a human_error message

Would that satisfy your needs?

[adam-26]

@mwitkow you are correct in assuming I want to localize the error messages. I believe the requirements listed above are sufficient to achieve that. I think that it would be easier for the developer if the field name was returned, and not the field id.

[mwitkow]

@adam-26 @sigmonsays:
Just an FYI, I haven't forgotten about this bug. But I've been working on field-based reporting in JSONpb (see golang/protobuf#266). As I'm waiting for input by the golang protobuf maintainers, I decided to hold work on field validator errors, to make sure they are consistent with whatever (if anything at all) lands in jsonpb.

[mwitkow]

Still waiting on upstream. :(