[
https://issues.apache.org/jira/browse/THRIFT-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632813#action_12632813
]
David Reiss commented on THRIFT-135:
------------------------------------
Normally we try to use the default collection types that the language provides
to make Thrift feel more native. However, I think this is a bigger deal in C++
which uses nonvirtual methods. I think this would be okay in Java since the
focus is more on the Set interface than any particular Set class. However, we
should keep in mind that an application developer can put any Set
implementation into a structure, so we would still have to do checking on
serialization (unless we're okay with just throwing a null pointer exception).
> Nulls in set<string> throw an exception in Java
> -----------------------------------------------
>
> Key: THRIFT-135
> URL: https://issues.apache.org/jira/browse/THRIFT-135
> Project: Thrift
> Issue Type: Bug
> Components: Compiler (Java)
> Reporter: David Reiss
>
> From Amit Sudharshan:
> I recently noticed a bug(feature?) in
> com.facebook.thrift.protocol.TBinaryProtocol.writeString where if it is
> passed a null pointer it will throw NPE.
> Now, the autogenerated stub code tries to prevent this, however we recently
> came across a case where we had a Set<String> which contained a "NULL" (legal
> in java). Thrift tests to see if the set is non-null and implicitely whether
> it has any elements, both of these pass in this case, and so the null string
> is passed to the writeString method where we get the NPE.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
