Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Safe error handling for rule-based type customization #228

Open
chaddaksha opened this issue Sep 2, 2022 · 1 comment
Open

Safe error handling for rule-based type customization #228

chaddaksha opened this issue Sep 2, 2022 · 1 comment

Comments

@chaddaksha
Copy link

Hi,

I'm trying to automatically map protobuf types to refined types. Is it possible to do so in a safe way that would allow for easy error handling (i.e., as opposed to throwing)?

For example, Validator[MyType].validate(request) returns a list of failures when validate_at_construction is set to false. I would like similar behavior for type mappers.

One workaround I can think of is to avoid type mapping and instead just use the Validator instance, then perform unsafe operations (NonEmptyString.unsafeFrom), assuming the data has already been validated based on the appropriate rules.

Thank you,
Chad Daksha

@thesamet
Copy link
Contributor

thesamet commented Sep 2, 2022

Hi @chaddaksha , this is a valid issue, though introducing TypeMappers that can collect errors lead to a fairly large change in ScalaPB that is unlikely to be introduced due to complexity added versus user demand. (I am open to be convinced otherwise if we see demand for this showing up in the future)

For the time being, we can consider something along the lines of your suggestion: maybe you can find a way to generate the case classes twice, one with a permissive structure (String), and one with the refined structures, do validation on the permissive type and unsafe conversion to the second.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants