There does not currently exist a mechanism for doing this. Exceptions in service handler methods are considered application concepts, which are intentionally sandboxed/abstracted from the Thrift server internals.
It sounds like what you want here is actually control-flow from the handler to the server -- you want the application handler to be able to tell the server to not even respond under certain circumstances. I can think of two reasonable ways of doing this: (1) Expose an API to the processor that application handlers can invoke. Rather than throwing an Exception, your application handler would explicitly call something like TProcessor::abortCall(). (This could perhaps be implemented by just having abortCall() throw a specific, internal Exception type, like TProcessorCallAbortedException, which we could then internally catch and use to suppress the response.) Pros: explicit, clear semantics, likely pretty easy to implement Cons: breaks abstraction between application code and Thrift internals, handler no longer makes sense if not running in a Processor (2) Implement an "Observer" abstraction in the TProcessor that lets you plug in a custom handler that inspects the result of a service call and either continue or take a different action. I don't think this should be Exception-specific. Exceptions are just one type of response that an applicaton may generate. You may also want to do something special when "0" is returned, or some other sentinel, etc. Pros: Application-code stays clean and generic Cons: A bit opaque, unclear to application-code which responses will actually make it back to the client. Definitely harder to implement in C++ due to polymorphism of returned types. >> In the version of thrift I branched from some time ago, the process() call >> returned a bool This bool indicates whether processing should continue. If the processor knows it's at the end of the input stream, it returns false to signal that process() should not be called again. Hope this helps. Interested to hear what other ideas folks have on this. I'll have to mull it over further but at the moment my gut says (1) above is probably the cleanest solution. Cheers, mcslee -----Original Message----- From: Soules, Craig [mailto:[email protected]] Sent: Thursday, September 16, 2010 12:39 PM To: [email protected] Subject: [PLEASE HELP] Question regarding server-side noticification of server function exceptions Re-posting hoping someone will see this. -----Original Message----- From: Soules, Craig Sent: Thursday, September 09, 2010 2:55 PM To: [email protected] Subject: Question regarding server-side noticification of server function exceptions Hi all, I am trying to determine if there is a way for a server calling thrift::TProcessor::process() to be notified if there was an exception during the execution of the underlying RPC call. The reason I ask is that in some cases, I would prefer that my server drop the client connection rather than (or in addition to) notifying the client that there was an error (e.g., in the case of invalid credentials). In the version of thrift I branched from some time ago, the process() call returned a bool, which I thought might be the error notification, but the auto-generated thrift rpc processing code always returned true, making this return code somewhat useless. In case it isn't clear from above, I am running our own thrift server, as we needed additional functionality and hooks regarding notification of client connection and disconnection which could not be achieved with the basic thrift server. I also was forced to branch due to the lack of native Windows support in Thrift, so apologies if this has been changed/fixed in the latest version (although looking at the source code online, it appears it has not?) Thanks, Craig Soules
