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

provide additional option to use custom error handler for set_root_schema #187

Open
BitFis opened this issue Nov 30, 2021 · 10 comments
Open

Comments

@BitFis
Copy link

BitFis commented Nov 30, 2021

Would it be possible to extend the json_validator::set_root_schema(json &&schema) function to allow also a custom error handler like json_validator::validate(...) has?

This would allow me to provide a more precise and user custom error than the exception provides. I am happy to provide a MR if this feature is welcome. I propose following extension:

// error_handler and works the same way than validator error_handler
void json_validator::set_root_schema(json &&schema, error_handler &err);

I am also open for alternatives.

Cheers

@BitFis BitFis changed the title provide additional option to set_root_schema for error handling provide additional option to use custom error handler for set_root_schema Nov 30, 2021
@pboettch
Copy link
Owner

pboettch commented Dec 1, 2021

You mean, instead of the thrown exceptions in case of errors? Are there that many errors thrown when setting the root schema?

@BitFis
Copy link
Author

BitFis commented Dec 1, 2021

Providing a schema via argument / startup of the application provided by the user those erros will occure. I agree that those errors do not occure as often, but they will occure and providing precise information via error_handler will help fix those. Also I am planning to integrate this schema validator in an embedded environment which will have exceptions turned off.

@pboettch
Copy link
Owner

pboettch commented Dec 1, 2021

I see your point, but I'm unsure which kind of finer graded error-messages this would provide by just having a callback called instead of an exception.

The schema is so free in what can be done with it. There is no schema-syntax check when setting the root-schema, wrong fields will silently be ignored (and maybe treated as unknown keywords).

@BitFis
Copy link
Author

BitFis commented Dec 1, 2021

That is great, but I ran into the issue when I referenced to an non existent ref. object. Aka, it throws in case of #/bad/ref. So it seems only maybe for this specific use case it makes sense.

@pboettch
Copy link
Owner

pboettch commented Dec 1, 2021

What would you think if dedicated exceptions would be thrown for the errors? I'd prefer actually.

@BitFis
Copy link
Author

BitFis commented Dec 2, 2021

And the exception would be extended with a json pointer containing location of the bad reference and the bad reference? That would work.

@pboettch
Copy link
Owner

pboettch commented Dec 2, 2021

I know this is possible in Python, but is this doable in C++? Customizing exceptions arguments? I'd be happy to have a look if you'd have some time to try out something that fits your needs. Also see this issue, which would be then related:

#37

@BitFis
Copy link
Author

BitFis commented Dec 2, 2021

Well, I am not the biggest expert, but as I would do it is extend std::exception or probably better extend json::exception and overwrite const char* what(). In nlohmann::json it seems it's done a bit different, I would check how they did it and reuse as much (https://github.com/nlohmann/json/blob/develop/include/nlohmann/detail/exceptions.hpp)

@pboettch
Copy link
Owner

Sounds good. What would be a estimated time of arrival if you could get your hands on it?

@miguelxmiguel
Copy link

Hi, It would be very usefull to be able to turn off exceptions for when they are not supported:
https://json.nlohmann.me/features/parsing/parse_exceptions/#switch-off-exceptions

Otherwise any issues parsing a root schema will throw an exception.

Thanks

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

No branches or pull requests

3 participants