[
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
