-
-
Notifications
You must be signed in to change notification settings - Fork 6.9k
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
Add support of nullable fields to NLOHMANN_DEFINE_TYPE_NON_INTRUSIVE and NLOHMANN_DEFINE_TYPE_INTRUSIVE #2356
Comments
This is not a bug, but the expected behavior of the macros. If you need anything beyond a mapping of members to object keys, you need to define your own conversion functions, just as you did. |
Thank you for the clarification! |
I think changing the existing macros' behavior would not be helpful as this would break existing code. I'm not sure whether adding another pair of macros like |
can we use Datatypes are mentioned here |
Optionals are a C++17 feature. We are working on support for built-in support for them, see #2229. |
I don't think |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
What is the issue you have?
When I try to deserialize JSON which contains nullable string fields into an object with (de)serializers generated by NLOHMANN_DEFINE_TYPE_NON_INTRUSIVE macro, the program throws an exception at this point:
from_json.hpp line 80
error:
Exception thrown at 0x764A4DBD in TrelloBackup.exe: Microsoft C++ exception: nlohmann::detail::type_error at memory location 0x00FAE7B8.
Unhandled exception at 0x764A4DBD in TrelloBackup.exe: Microsoft C++ exception: nlohmann::detail::type_error at memory location 0x00FAE7B8.
Exception thrown: read access violation.
_Right was nullptr.
Please describe the steps to reproduce the issue.
Create a json like this:
Define classes like this:
Then try to deserialize:
I had to write custom (de)serailizers to handle nullable fields like this:
What is the expected behavior?
I would expect the logic generated by macros not to crash if it stumbles upon a nullable field, but set nullpointr or some default value to the field.
And what is the actual behavior instead?
Exception is thrown.
Which compiler and operating system are you using?
Which version of the library did you use?
If you experience a compilation error: can you compile and run the unit tests?
The text was updated successfully, but these errors were encountered: