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
value_to of a wrong sized Object return an error a bit misleading and a bit to improove #904
Comments
There's basically no way to put that information into the The error message is indeed misleading though, so I will change it. |
Yes I tried to play around the error_code, and the only way to carry such information will be abusing the
Which Is orrible to say the least. Do you have any suggestion on how to use a custom handler ? I tried to play around, but I have no idea except review the whole value_to system to have allow customization point (some kind of visitor pattern) I am currently trying a macro based approach, so only if someone is willing to pay this price is enabled. |
Wait, disregard my suggestion for handler, it has nothing to do with value_to. I guess, there's no way to do this except for using a completely custom conversion system. |
Do you think a macro based approach can be ok ? (before value_to invocation, in the userland code) Inside actual library code a few of and in case of error you will have (in user land) Of course the use of try_value_to will be needed in that case to properly operate. |
Are you suggesting that we add this to the library? I don't think we'll do that. |
Think is not a "hard" no... If you want we can discuss on the slack channel too. |
If you really want to make such a proof of concept, I can't stop you. But the chances of it getting adopted are very slim. |
Well in any case I need for myself, and it will be far easier than rewire a value_to subsytem. |
How would it even work without patching every value_to helper? What is supposed to call push and pop? |
Still thinking about it. So you define this class before starting the value_to chain of operation in userspace code. You also have to define the 2 macro push and pop to operate using it and not to be a NO-OP That is more or less the idea, which I took just a few line below here json/include/boost/json/detail/value_to.hpp Line 516 in be759c5
|
Actually, now that I think about it, it might be possible to achieve this using contextual conversions (a new feature that will be in 1.83). |
I am all hears... what is this and can I do something ? |
This could actually be an interesting example. |
Keeping track of the path in the context in one way to do it, but the exception must still propagate upwards unscathed. (This can be done by the user via a custom context.) The other way of doing this is building the path on the way up as the exception propagates. (This can't be done by the user and must be done by Boost.JSON.) |
Version of Boost
1_82
Steps necessary to reproduce the problem
https://godbolt.org/z/7jdn9xh6f
The returned error is
Which is a bit misleading, it should be object size, but the problem is the lack of context, working with a big json will quickly require to have to use a debugger to pinpoint the actual element which had the error.
I think an error like, would be much better
Now I do understand the implication of building a json pointer for all the element can easily be a performance killer, so maybe defining a macro can be a viable option ?
Or I can try to play with somekind of linkedlist structure to store the string_view of the key that composes the path, and in case of error is assembled and used.
The text was updated successfully, but these errors were encountered: