I agree that throwing NPE makes sense as I can see bad things
happening with the other cases (discrepencies in length, and ""
replacing null could break if/then logic).
I don't think I read this limitation on the docs, but could be wrong.
-Amit
Sent from my iPhone
On Sep 8, 2008, at 12:39 PM, "David Reiss (JIRA)" <[EMAIL PROTECTED]>
wrote:
[ https://issues.apache.org/jira/browse/THRIFT-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12629225#action_12629225
]
David Reiss commented on THRIFT-135:
------------------------------------
I'm open to suggestions on how we should deal with this. My
instinct is that we should not allow nulls in sets since they cannot
be represented in C++ or PHP (though they can in Python). If we
take that approach, I guess the choices are:
1/ Continue throwing an exception.
2/ Silently convert to "".
3/ Silently drop from the set.
Thoughts?
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.
