[racket] tcp exceptions and connection reestablishment...

Sorry for being unclear. Of course I'm not asking for production level  
code nor critizing your very helpful sketch.

This is more about control flow and how to realize it. To me it looks  
as if the designers of the Racket TCP wrappers took the following road  
(pseudo code of course):

submit a socket call. If failure, read the error code and raise an  
exception with it, otherwise return whatever appropriate for the  
function.

I understand that the BSD socket API itself has a number of glitches  
and shortcomings that make it hard to build a consistent model around  
it (eg, a recv() on a closed socket may return 0 instead of the usual  
-1 for error, and some error conditions like send() on a closed socket  
may not return errors at all because all a successful send() indicates  
is that there was space in the outgoing buffer). Of course there is  
nothing Racketr can do to clear these up.

An alternative approach to translate BSD to Racket would have been to  
map the calls somewhat 1:1 to the wrappers and define some special  
error type that can be distinguished from success returns and that  
could be processed "inline."

Of course I'm biassed, having programmed network software for almost  
20 years now, but I have difficulties seeing how the "non linear"  
exception control flow could actually make writing code easier (my  
experience is that *everything* is easier to code in Racket as opposed  
to C so that's why I'm surprised that there is no obvious and elegant  
solution in Racket in this case). I sort of wish I had an option to  
use a linear control flow instead unless of course somebody opens my  
eyes and says "look here stupid! It's easy, right before you - do this  
and that and you've coveresd everything" (which normally happens when  
I ask questions in this forum).

I have a feeling in the back of my head that the concept "non linear  
control flow through exception handling" may be overdone in some  
instances (in particular when there are several things that can go  
wrong which manifest themselves in sometimes subtle diferent ways).

Thanks again!

Quoting Neil Van Dyke <neil at neilvandyke.org>:

> I began by saying "This is quick off-the-cuff suggestion to consider,
> not the only way to do this (nor any kind of canonical recipe for doing
> this sort of thing, nor necessarily the best way)" for three reasons:
> (1) I think the right solution varies with the subtleties of one's
> application; (2) getting the networking code exactly right for a
> particular application takes a lot more head-scratching than banging
> out an email does; (3) if I had the perfect reusable code pattern
> already, I think it would be in a PLaneT package or a book chapter. :)
>
> You mention "set!".  I think my eventual solutions to this kind of
> problem would usually look similar in style to that example I gave, but
> if I decided that "set!" would be helpful, I wouldn't be afraid to use
> it.  I'd probably have to spend hours working through details before I
> got to that point.  You also mention uniform handling; as you are
> refining your app's networking code, if you find you really don't want
> a particular procedure to return an exception, you can always wrap the
> call site tightly with a "with-handlers" that makes it return an error
> value instead,
>
> Perhaps someone else has different suggestions.
>
> Neil V.