You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Billy Newport (JIRA)" <ji...@apache.org> on 2011/03/02 02:48:37 UTC
[jira] Created: (THRIFT-1077) binary can't be null in 0.5
binary can't be null in 0.5
---------------------------
Key: THRIFT-1077
URL: https://issues.apache.org/jira/browse/THRIFT-1077
Project: Thrift
Issue Type: Bug
Components: C++ - Library
Affects Versions: 0.5
Environment: Mac Snow leopard
Reporter: Billy Newport
Priority: Blocker
Fix For: 0.5
I had code working on thrift 0.3. I had a java server and C++ client. I have a thrift method like:
binary get(1:string mapName, 2:binary key)
This used to return null when the key isn't found. It used to return a byte[]. I noticed that 0.5 uses ByteBuffers everywhere instead of byte[]s so I converted my server. This method implementation returns null if the key isn't found but this fails on the client side with a:
terminate called after throwing an instance of 'apache::thrift::TApplicationException'
what(): get failed: unknown result
Do I need to handle null binaries with a special code or exception now? This is clearly different behavior than was present in 0.3
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (THRIFT-1077) binary can't be null in 0.5
Posted by "Bryan Duxbury (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bryan Duxbury closed THRIFT-1077.
---------------------------------
Resolution: Invalid
Fix Version/s: (was: 0.5)
> binary can't be null in 0.5
> ---------------------------
>
> Key: THRIFT-1077
> URL: https://issues.apache.org/jira/browse/THRIFT-1077
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
> Affects Versions: 0.5
> Environment: Mac Snow leopard
> Reporter: Billy Newport
> Priority: Blocker
>
> I had code working on thrift 0.3. I had a java server and C++ client. I have a thrift method like:
> binary get(1:string mapName, 2:binary key)
> This used to return null when the key isn't found. It used to return a byte[]. I noticed that 0.5 uses ByteBuffers everywhere instead of byte[]s so I converted my server. This method implementation returns null if the key isn't found but this fails on the client side with a:
> terminate called after throwing an instance of 'apache::thrift::TApplicationException'
> what(): get failed: unknown result
> Do I need to handle null binaries with a special code or exception now? This is clearly different behavior than was present in 0.3
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (THRIFT-1077) binary can't be null in 0.5
Posted by "Seth Hitchings (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13001553#comment-13001553 ]
Seth Hitchings commented on THRIFT-1077:
----------------------------------------
You can also generate code that uses byte[] instead of ByteBuffer: https://issues.apache.org/jira/browse/THRIFT-872
> binary can't be null in 0.5
> ---------------------------
>
> Key: THRIFT-1077
> URL: https://issues.apache.org/jira/browse/THRIFT-1077
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
> Affects Versions: 0.5
> Environment: Mac Snow leopard
> Reporter: Billy Newport
> Priority: Blocker
>
> I had code working on thrift 0.3. I had a java server and C++ client. I have a thrift method like:
> binary get(1:string mapName, 2:binary key)
> This used to return null when the key isn't found. It used to return a byte[]. I noticed that 0.5 uses ByteBuffers everywhere instead of byte[]s so I converted my server. This method implementation returns null if the key isn't found but this fails on the client side with a:
> terminate called after throwing an instance of 'apache::thrift::TApplicationException'
> what(): get failed: unknown result
> Do I need to handle null binaries with a special code or exception now? This is clearly different behavior than was present in 0.3
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (THRIFT-1077) binary can't be null in 0.5
Posted by "Bryan Duxbury (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13001327#comment-13001327 ]
Bryan Duxbury commented on THRIFT-1077:
---------------------------------------
I don't think we are planning to support returning null. For better or worse, the way that we indicate "success" in the RPC is by the result being set or unset. If you return a null binary value, then it's indistinguishable from a failure.
The way that I personally work around the problem is by making my methods return a wrapper struct (get -> GetResult) that has a binary field that can be null. That way, you're always returning something non-null, but null can be the contents of the message.
If it worked in 0.3, then it was probably a fluke.
> binary can't be null in 0.5
> ---------------------------
>
> Key: THRIFT-1077
> URL: https://issues.apache.org/jira/browse/THRIFT-1077
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
> Affects Versions: 0.5
> Environment: Mac Snow leopard
> Reporter: Billy Newport
> Priority: Blocker
>
> I had code working on thrift 0.3. I had a java server and C++ client. I have a thrift method like:
> binary get(1:string mapName, 2:binary key)
> This used to return null when the key isn't found. It used to return a byte[]. I noticed that 0.5 uses ByteBuffers everywhere instead of byte[]s so I converted my server. This method implementation returns null if the key isn't found but this fails on the client side with a:
> terminate called after throwing an instance of 'apache::thrift::TApplicationException'
> what(): get failed: unknown result
> Do I need to handle null binaries with a special code or exception now? This is clearly different behavior than was present in 0.3
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira