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.
Create a json like this:
{
"cover":{
"idAttachment":null,
"color":null,
"idUploadedBackground":null,
"size":"normal",
"brightness":"light"
}
}
Define classes like this:
#pragma once
#include <string>
#include <vector>
#include <nlohmann/json.hpp>
using namespace std;
using json = nlohmann::json;
namespace TrelloDtos {
class CoverDto {
public:
string idAttachment;
string size;
};
class CardDto {
public:
CoverDto cover;
};
NLOHMANN_DEFINE_TYPE_NON_INTRUSIVE(CoverDto, idAttachment, size)
NLOHMANN_DEFINE_TYPE_NON_INTRUSIVE(CardDto, cover)
}
Then try to deserialize:
voidTrelloApi::findCards(string response) {
json jsonObj = json::parse(response);
CardDto cardDto = jsonObj .get<CardDto>(); <--- at this point the exception is thrown
}
I had to write custom (de)serailizers to handle nullable fields like this:
void TrelloDtos::to_json(json& j, const CoverDto& p) {
j = json{ {"idAttachment", p.idAttachment},{"size", p.size} };
}
void TrelloDtos::from_json(const json& j, CoverDto& p) {
auto idAttachment = j.at("idAttachment");
if (!idAttachment.is_null()) {
idAttachment.get_to(p.idAttachment);
}
auto size = j.at("size");
if (!size.is_null()) {
size.get_to(p.size);
}
}
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.
Exception is thrown.
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 am curious, would it make sense to improve those macros to handle possible nullability (or absence) of fields?
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 NLOHMANN_DEFINE_TYPE_NON_INTRUSIVE_NULLABLE would be a good idea. Any thoughts?
can we use std::optional for C++ data types used in nlohmann::json This way we can add support of std::nullopt for values atleast.
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 NLOHMANN_DEFINE_TYPE_NON_INTRUSIVE_NULLABLE would be very useful after #2229 is merged in?
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.
Most helpful comment
Optionals are a C++17 feature. We are working on support for built-in support for them, see #2229.