You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think it should throw an exception if a field exists in both the thrift definition and in the object being deserialised but the types do not match, regardless of optionality. This suggests that the thrift object is not of the correct format and all bets are off on whether the rest of the data is actually what you expect.
If the field exists in the object being deserialised but does not exist in the thrift definition, I think this should be ignored. This suggests that the object being deserialised is using a backwards compatible newer version of the thrift definition, which shouldn't be a problem.
The parser silently ignores a missing field. This isn't the correct behaviour and should throw an exception.
However what do we want to do if the field is present and with the wrong type?
I'm leaning towards throwing an exception in all cases but I'm happy to have my mind changed.
We'll also need a test case for both these cases, which will have to happen in the js part of the tests.
The text was updated successfully, but these errors were encountered: