> >> To be clear, it would also be nice to have the server understand > what exception was thrown in some cases, as to allow for proper > cleanup. > > What you're asking for sounds like it would really blur the lines > between the Thrift internals and your application logic. This sounds > like application-layer error-handling to me. If you need to do > different types of cleanup based upon exception types, my opinion is > that you should have a catch() block in your implementation, and you > should only communicate to the Thrift internals exactly *what* action > to take. The Thrift internals should just take actions, but I think > they should not be tasked with *mapping* types of application > exceptions to those actions. That's your application's logic.
There may be cases where the server would want to send an exception to the application and after that immediately close the client connection. Its less a specific mapping I suppose than a general class of exceptions (any of those which would terminate the client connection). > >> One thing I noticed is that if my exception is not derived from > std::exception, then the TProcessor won't catch and wrap it... the > question is, will it be safe to continue to use the processor in this > case? > > I'm not sure off the top of my head. My assumption is that the client > will end up dead (or worse) and you'll need to create a new one. I was more worried about the server-side being able to continue in this case than the client-side. I'll probably just dig a bit deeper into the code to get the answer to this. > >> Another thing I had thought about was simply modifying the thrift > code to rethrow the exception once it was done packing up the response, > allowing me to catch on the server side and take whatever action we > deem appropriate. > > Sounds reasonable, but why not just do this (catch-and-rethrow) in your > application code? What is the benefit of pushing this logic down-stack? Likely it would be solely for the purpose of being able to close the client connection immediately rather than relying on the client to do so. There may be other cases (?) but nothing comes to mind right now. Thanks again! Craig
