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] Closed: (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: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