Re: [boost] sockets /network programming Requirements

From: Josh M Osborne (stripes_at_[hidden])
Date: 2001-07-30 16:16:10

On Mon, Jul 30, 2001 at 03:15:19PM -0400, Lyell E. Haynes wrote:
[...]
> I am a little interested to hear what others have to say about using
> exception based failure mechanisms rather than return codes. Do you
> really need people to be putting every little socket function in a
> try/catch block in order to run safely?

I write a whole lot of network code (and have for the last 8 years).
Almost every socket call I make ends up doing something like

  int fd = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP);
  if (fd < 0) {
        throw sys_fd_error(errno, fd, "socket", __PRETTY_FUNCTION__);
  }

or something similar (less elaborate error classes, or an error
class that doesn't have the fd for the cases were it is an error
return, not an fd...or for very old code (1992ish) just a plain
ol' assert).

The only error I have written code to retry is socket connects that
try each address in a list (IPv4 and IPv6 in fact), and in one case
some read errors can trigger another http GET with a range request
(EIO, ECONNABORTED, ECONNRESET,  ETIMEDOUT, ENETRESET, ENETUNREACH,
ENETDOWN, EHOSTDOWN, EHOSTUNREACH, ECONNREFUSED, and for some reason
ENOBUFS).  The get request will cycle through the list of addresses
again so things like EHOSTDOWN or ENETUNREACH can be "corrected"
that way.

I would rather make those two socket calls out of the 100s I make
somewhat more complex, and slower and have all the others *right*.

Otherwise I'm likely to forget to do a check (or check a return
code for <=0 where !=0 is the real condition).

At least that's why my code (when using C++ on a platform that
supports exceptions at least) uses exceptions (and in fact frequently
uses a very thin wrapper layer that calls the normal Unix network
stuff, and then throws an exception if it gets an error return).

NOTE: I'm not counting short reads/writes or EOF as an error.

>                                          What about instances where an
> application will still want to continue running after a failure, just
> without network support. It seems to me to be simpler to just let the
> application check the return codes, rather than deal with the complexities
> of setting it's own error codes in each catch block.

I don't think

  try {
        socket stuff;
  } catch (socket_exception &) {
        do_no_more_net_io = true; 
  }

is really much more complex then checking for an error code from
a socket call, and it is definitely simpler if there are two socket
calls in "socket stuff", let alone three or 8.  Hopefully it will
be clear what exception(s) go where "socket_exception" is, it would
be nice if there was only one, but there may be other reasons not
to have a single super class for all socket exceptions.

Clearly for code where socket errors are program errors:

  socket stuff;

Is a whole lot less complex then checking each return code.

[...]
> I also think that TCP/IP should be the basis of this design, but it
> shouldn't be the only thing included. It should be used to get the library
> started, but it might be useful to be able to add more protocols later as
> the need arises, so some amount of generalization in that area should be
> required.

It would definitely be useful to have other things (UDP, ICMP),
but even if all it can do is TCP, it is useful.