I'm going to have a look at this too. As well as being sub-optimal in terms of performance it's a pain when debugging a C# server.
what repo. is this code in? On 28 May 2014 08:04, Jens Geyer <[email protected]> wrote: > +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. > > > > >
