+1 but it is not only the C# code. This pattern is used elsewhere too. That doesn't make it better. ________________________________ Von: Randy Abernethy Gesendet: 28.05.2014 06:58 An: [email protected] Betreff: Re: Unnecessary Exceptions
Hi Craig, I agree with your assessment of exceptions in normal control flow. If you can provide a patch that improves on the C# server solution we'll certainly review it! Best, Randy On Tue, May 27, 2014 at 12:58 PM, Craig Peterson <[email protected]>wrote: > 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. > >
