I am looking through the C# server code, and was surprised at the try/catch mechanisms being used. The Server does a while (processor.Process(inputProtocol, outputProtocol)) loop to process all requests on a given connection. The processor in turn calls ReadMessageBegin and catches IOExceptions (which do not appear to be throwing for me). What is happening on every request is that the protocol is throwing a TTransport exception when the stream is closed, and the server is catching it.
Everything technically works correctly, but I am not so comfortable with Exceptions being thrown and caught on EVERY request to my server. I don't have hard numbers on the performance impact of throwing and catching exceptions in .net, but I do know that exceptions have a real cost, and should be avoided for control-flow type scenarios. Is there a better way to detect if there is another request on the stream than trying to read it and letting it throw if there is nothing there, or if the socket is closed? I tried playing around with reading transport.IsOpen in various places, but that does not seem to be reliable enough to act as a signal. In my case I know that no client will make multiple requests on a socket, so I can even make my own server that doesn't loop over the processor, but I am not so happy about that either.
