-
-
Notifications
You must be signed in to change notification settings - Fork 6.7k
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
Better diagnostics #2562
Better diagnostics #2562
Conversation
Thanks @gregmarr for the comments! I will look at them in detail later this week. |
There is a missed point. The following assigment will be lost after the object is moved to the container: json/include/nlohmann/json.hpp Line 1646 in d4a91b7
|
Unfortunately, I cannot create an example where the parent is lost. Would you propose setting the parent after calling |
I think it can be done something like this: karzhenkov/json@22bd1e1 |
@gregmarr @karzhenkov I think this branch is ready now. Any further comment or observation? |
Here are also some proposals to undo unnecessary changes and make the code a bit more concise: karzhenkov#1 |
Co-authored-by: Alexander Karzhenkov <[email protected]>
I took over some of your ideas: 74cc0ab. What do you think? |
It would also be nice to get rid of the empty json objects that are created in many places just to indicate "no diagnostics". This can be achieved with an overload of json/include/nlohmann/detail/exceptions.hpp Lines 187 to 188 in 74cc0ab
Other similar function templates need the same defaults. As a possible point of additional extension, we can also consider other types of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ugh, started a review yesterday and forgot to submit it.
@@ -137,7 +137,7 @@ class binary_reader | |||
if (JSON_HEDLEY_UNLIKELY(current != std::char_traits<char_type>::eof())) | |||
{ | |||
return sax->parse_error(chars_read, get_token_string(), | |||
parse_error::create(110, chars_read, exception_message(format, "expected end of input; last byte: 0x" + get_token_string(), "value"))); | |||
parse_error::create(110, chars_read, exception_message(format, "expected end of input; last byte: 0x" + get_token_string(), "value"), BasicJsonType())); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this just be {}
instead of BasicJsonType()
? (Not sure now what works in C++11 and what requires later versions.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm assuming that you want to be explicit about not providing a json
object here and so don't want a default parameter value.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried earlier to work with a default value, but I got an error that the type could not be derived. I'll give it another check later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, it's a templated parameter, yeah that makes it harder to have a default.
…ostics � Conflicts: � include/nlohmann/detail/input/parser.hpp � single_include/nlohmann/json.hpp
LGTM |
This PR improves the diagnostic information provided by the library in case of exceptions. The idea (originally described in #1508 (comment) and #932 (comment)) is that every JSON value in an array or object contains a pointer to the enclosing container. From this parent relation, we can generate a JSON Pointer to the current value that allows to identify the erroneous value. As we need to store one additional pointer per JSON value, the diagnostic mode is guarded by a preprocessor macro
JSON_DIAGNOSTICS
that needs to be defined in order to enable the better diagnostics.This PR is work in progress. There are a lot of open tasks, including
Any help, input, review, or discussion is greatly appreciated!
Closes #1508. Closes #932. Closes #2552.