[
https://issues.apache.org/jira/browse/THRIFT-807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12891337#action_12891337
]
Roger Meier commented on THRIFT-807:
------------------------------------
I'm not sure if that's a JavaScript issue, probably I did not understand the
real problem before!
Due to the fact, that all Languages supported by Thrift do initialize types,
objects, etc. in a different ways, the base types might be initialized
correctly by setting them to 0. => null is a JavaScript specific thing!
I think it is required to extend the
[[ThriftTypes|http://wiki.apache.org/thrift/ThriftTypes]] Definition by
enforcing default values for all ThriftTypes. So that not initialized Types or
Objects are absolutely the same on wire.
> JavaScript: Initialization of Base Types with 0 instead of null
> ---------------------------------------------------------------
>
> Key: THRIFT-807
> URL: https://issues.apache.org/jira/browse/THRIFT-807
> Project: Thrift
> Issue Type: Bug
> Components: Compiler (JavaScript)
> Affects Versions: 0.3
> Reporter: Roger Meier
> Attachments: THRIFT-807_initialize_with_null.patch,
> THRIFT-807_initialize_with_null.v2.patch
>
>
> I had a problem with the exception avaliable on the tutorial.
> i32 calculate(1:i32 logid, 2:Work w) throws (1:InvalidOperation ouch),
> It couldn't be thrown because initialization of numeric base types is done
> with 0 instead of null and the checks do compare against null.
> This was not visible with the Tests provided with first patch for JavaScript
> bindings above, the ThriftTest.thrift definition does not have a combination
> of a base type return value and an exception.
> I've made a patch that initializes the base types I16,I32, I64 and DOUBLE
> with null. This could probably solve other issues as well
> Regards
> Roger
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
