Hi all, I'm implementing exception-handling and I'm a little surprised at how they're handled in the Thrift protocol. As far as I can tell, the following statements are true:
- User-defined exceptions and the return value are packed into a single function_result struct - If we read a message_begin marker from the input protocol and it has type TMessageType::Exception, then it's an _unknown_ application exception - If we read a message_begin marker from the input protocol and it has type TMessageType::Reply, then we deserialize it into the function_result struct. The reply (and this struct) may contain *either* the defined result type or (any of) the user-defined exceptions I understand why args and returns/exceptions are packed into structs: it allows us to define a packing structure and reuse it to marshal values to/from the wire. I am however, surprised that a service call throwing a user-defined exception is still identified as a TMessageType::Reply. I expected the following approach: - We generate a function_exception struct that has all user-defined exception types (members are optional) - We generate a function_return struct that has the return value (members are required) - If the service call throws an exception the call returns with TMessageType::Exception, which is then unpacked into the function_exception struct - If the service call succeeds the call returns with TMessageType::Reply, which is then unpacked into the function_return struct The big downside I can see with the approach above is dealing with random exceptions thrown by the remote side. If it's an unexpected exception, unpacking the input protocol into function_exception would fail, and there'd be no way to tell if (de)serialization was broken or whether it was an unexpected exception. At any rate, I am _not_ suggesting changing the thrift protocol! I'm just curious what the rationale behind the existing design is. Is it (as I suspect) entirely a consequence of having to support random exceptions from the remote side? Thanks, Allen Terminal Musings: http://www.allengeorge.com/ Raft in Java: https://github.com/allengeorge/libraft/ Twitter: https://twitter.com/allenageorge/
