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(I AsyncResult ar){
StateObject so = (StateObject) ar.AsyncState;
Socket s = so.workSocket;
int read = s.EndReceive(ar );
if (read 0) {
so.sb.Append(En coding.ASCII.Ge tString(so.buff er, 0, read));
s.BeginReceive( so.buffer, 0, StateObject.BUF FER_SIZE, 0,
new
AsyncCallback(A sync_Send_Recei ve.Read_Callbac k), 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.WriteLi ne(String.Forma t("Read {0} byte from socket" +
"data = {1} ", strContent.Leng th, 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" <mi***@zeroc.co mwrote in message
news:11******** **************@ k79g2000hse.goo glegroups.com.. .
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.
