You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Bryan Duxbury (JIRA)" <ji...@apache.org> on 2011/03/02 08:56:37 UTC

[jira] Commented: (THRIFT-1077) binary can't be null in 0.5

    [ 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