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