Re: API Design: Is Socket.Select() seriously busted?

Michi,

I don't recall using this term in that context.

on page 5 you wrote:
(Another popular design flaw-namely, throwing exceptions for expected
outcomes-also causes inefficiencies because catching and handling exceptions
is almost always slower than testing a return value.)

This was what you wrote. What I ment, is that code like below - pasted
directly from VS2005 help for Socket class:

public static void Read_Callback(IAsyncResult ar){
StateObject so = (StateObject) ar.AsyncState;
Socket s = so.workSocket;

int read = s.EndReceive(ar);

if (read > 0) {
so.sb.Append(Encoding.ASCII.GetString(so.buffer, 0, read));
s.BeginReceive(so.buffer, 0, StateObject.BUFFER_SIZE, 0,
new
AsyncCallback(Async_Send_Receive.Read_Callback), so);
}
else{
if (so.sb.Length > 1) {
//All of the data has been read, so displays it to the console
string strContent;
strContent = so.sb.ToString();
Console.WriteLine(String.Format("Read {0} byte from socket" +
"data = {1} ", strContent.Length, strContent));
}
s.Close();
}
}is guaranteed to crash when the connection is lost, or the other side
disconnects forcefully, unless the code is wrapped into try/catch. Under
Win32 Winsock there was no need for using error trapping when responding to
socket events because WSAAsyncSelect() takesthe handle of the window
receiving notifications. .NET Sockets do not offer any means to notify the
application when the socket is aboutto 'bite the dust'. So we are using
error trapping for handling predictable situations. The sad thing, it is
easy to get used to. Michael
"Michi Henning" <michi@xxxxxxxxx> wrote in message
news:1191018452.661736.121970@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Sep 29, 12:18 am, "Michael Rubinstein"
<mSPAM_REMOVEr@m®ubinstein.com> wrote:
The part of the article I liked
most, is where the author condemns the API forcing the developer using
error
trapping for intercepting error that should not be anticipated.

There are tons of APIs around that throw exceptions when they
shouldn't. And, invariably, when they do, it causes grief for the
caller.

The author of the article calls the API design that encourages such
practices 'perverse', and I agree.

I don't recall using this term in that context. Not that I'd disagree
though. Asynchrnous reads from a .NET socket do exactly this: throw an
exception when for the expected outcome (namely, no data ready to
read), and return zero for the unexpected outcome (namely, connection
loss). Code that has to deal with this nonsense ends up looking very
contorted because of the mess of control flow.

Cheers,

Michi.


.

Relevant Pages

  • Re: Close a blocked socket
    ... from any other informational exceptions that occur in .NET. ... discards the socket, and the program code finds out about it the hard way. ... With 30 connections it ... I didn't "decide to go blocking". ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: socket calls send recv error handling questions
    ... There should not be any exceptions thrown from socket calls, ... example, that after you recva command the next recv, which gets some ... The WinSock calls don't throw C++ exceptions. ... My fear is that a heavy traffic network could ...
    (microsoft.public.windowsce.embedded.vc)
  • Re: error handling
    ... >> Lisa Pearlson wrote: ... >>> Imagine I have a socket read function.. ... >>> exit 1 ... > exceptions to return data yet allow additional info.. ...
    (comp.lang.tcl)
  • Re: Handling exceptions in Socket Callbacks
    ... You're correct the asynchronous socket methods give more opportunities ... I always handle exceptions in callbacks in the callback itself. ... why im using this complicated method of socket communication - ...
    (microsoft.public.dotnet.general)
Loading