Comments (8)
I'm all for this too. This will allow to map the errors to app specific errors which may include more context.
from go-proto-validators.
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?
from go-proto-validators.
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.
from go-proto-validators.
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
from go-proto-validators.
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?
"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?
from go-proto-validators.
@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.
from go-proto-validators.
@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.
from go-proto-validators.
Still waiting on upstream. :(
from go-proto-validators.
Related Issues (20)
- Does this work with APIv2? HOT 1
- go get report error, thanks for help
- could error message FieldName be json tag?
- import order changed
- Mask sensitive fields
- Support for multibyte strings
- is_in_enum combined with int_gt doesn't work
- Support for optional field HOT 4
- How to build this for NodeJS?
- nice, continue to update and iterate plase
- panic: interface conversion: interface {} is []uint8, not *validator.FieldValidator
- Error when building with bazel
- How to build this for python?
- Publish to buf schema register HOT 2
- is this repo still maintained? HOT 1
- How to specify path for generated validator.go ? HOT 2
- protoc command error
- Bad Code Generated HOT 1
- compiles files that dont have any validator notation
- generate code can not support option 'module' HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from go-proto-validators.